environment settings

[Ryan Schmidt]

On Nov 26, 2018, at 08:21, Mark Brethen wrote:

> On Nov 25, 2018, at 11:52 PM, Ryan Schmidt 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.
> 
> 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

Yes, I saw that the FreeBSD port does this. I am not familiar with FreeBSD ports, except that I've noticed that their ports are defined as Makefiles, likely with the full range of Makefile syntax at their disposal. MacPorts ports on the other hand are defined using a Portfile written in the Tcl language, with most of the Tcl syntax available. MacPorts conveniences should make writing custom Tcl code unnecessary in most cases, but for complex ports or poor build systems sometimes more of the work has to be done in Tcl code. Or you may be able to patch the project's existing Makefile to do what you want. Or you can of course write a custom Makefile, stash it in the files directory, and have the Portfile drive that, if that's easier; several ports do that already (see my lp_solve port for example).


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

My point was just that the custom build phase you showed us earlier seemed to be doing the same thing as the standard build phase, except offering fewer of the MacPorts conveniences. (It did not use ${build.env}, for example.) As such, it wasn't useful. If you need to do more than that, then overriding the build phase might indeed be needed. But consider whether allowing MacPorts to do the normal build phase, and then running additional parts of the build afterward in a post-build block, might make more sense.

I'm not certain that following a FreeBSD ports recipe to the letter is necessarily appropriate for MacPorts. For example, I see here that they make a copy of the configured source directory so that they can build libtaucs.a "normally" in the first directory and then with position-independent code in the second directory so that a shared library can be created from it. As far as I know, compilers produce position-independent code by default on macOS, so building the static library twice would not be necessary for us.

You asked in a separate thread how to create a macOS dynamic library from a static library (likely because you were trying to emulate what FreeBSD was doing here). I'd never considered trying that before. I'd probably focus instead on modifying the original Makefile to produce a macOS dylib directly from the existing object files, the way other projects' build systems do.