environment settings

[Mark Brethen]

This is how the bsd port builds taucs:



50	post-configure:
51	        @${CP} -r ${WRKSRC} ${WRKSRC}_SHARED
52	
53	archives: configure
54	        @${PRINTF} "\n\n%s\n\n\n" "Building libtaucs archives:"
55	        (cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
56	                ${MAKE} ${_MAKE_JOBS} ${MAKE_ARGS} lib/FreeBSD/libtaucs.a)
57	        (cd ${WRKSRC}_SHARED && ${SETENV} ${MAKE_ENV} PICFLAG="${PICFLAG}" \
58	                ${MAKE} ${_MAKE_JOBS} ${MAKE_ARGS} lib/FreeBSD/libtaucs.a)
59	
60	lib: archives
61	        @${PRINTF} "\n\n%s\n\n\n" "Building shared library:"
62	        (cd ${WRKSRC}_SHARED/lib/FreeBSD && \
63	                ${FC} ${CFLAGS} ${PICFLAG} ${LDFLAGS} -shared \
64	                -o libtaucs.so.1 -Wl,-x -Wl,-soname,libtaucs.so.1 \
65	                -Wl,--whole-archive libtaucs.a -Wl,--no-whole-archive)
66	        ${STRIP_CMD} ${WRKSRC}_SHARED/lib/FreeBSD/libtaucs.so.1
67	
68	bins: lib
69	        @${PRINTF} "\n\n%s\n\n\n" "Building (dynamically-linked) executables:"
70	#for the second pass through WRKSRC_SHARED, use a nonexistent MAKEOBJDIR to
71	#prevent make from entering the obj subdirectories and breaking the build (see,
72	#for example, the description of .OBJDIR in make(1)):
73	        (cd ${WRKSRC}_SHARED && \
74	                ${SETENV} ${MAKE_ENV} MAKEOBJDIR="${NONEXISTENT}" \
75	                ${MAKE} ${_MAKE_JOBS} ${MAKE_ARGS} ${BINS:S|^|bin/FreeBSD/|})
76	
77	do-build: bins

lib:archives builds the dynamic library, $(PICFLAG) is defined as


.if ${ARCH} == "sparc64"
39	PICFLAG?=       -fPIC
40	.else
41	PICFLAG?=       -fpic
42	.endif


bins:lib builds the executables defined as

BINS?=          direct iter taucs_run

I don’t know how to do all this with macports default build.


Mark Brethen
mark.brethen at gmail.com



> On Nov 25, 2018, at 11:52 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> 
> 
> On Nov 25, 2018, at 13:55, Mark Brethen wrote:
> 
>> I think their build process requires overriding the build phase in macports.
> 
> Why do you think that?
> 
> Their build process has no idea how their build process is being invoked. It should make no difference to their build process whether a command is called by the standard MacPorts build phase or by you manually running a command with system. But allowing MacPorts to use the standard build phase is almost always what you want to do, so that you can benefit from all of the conveniences that it offers.