Mark, I still think it would be easier to patch the build system to build the dynamic library and link the programs with it, rather than trying to call individual makefile targets from the portfile.
After looking at the build system for awhile, I see now why this project's build system is so difficult to modify: they don't use autotools or anything similar that would provide normal configure script or a template Makefile.in that you can easily patch. Instead, they provide a C program configurator/taucs_config.c that gets compiled and run which creates the makefile. But I was able to patch the configurator so that it generates a macOS dynamic library and use it instead of the static library. I've attached my files, based on yours, to the ticket: https://trac.macports.org/ticket/57669 I had intended that the static library would still get built, but it looks like the configurator has decided that since nothing depends on the static library anymore, it should not get built at all. As far as I'm concerned, that's fine; we prefer dynamic libraries anyway. I made some more changes: Added "dist_subdir ${name}/${version}" because the distfile is unversioned. Used "master_sites ${homepage}${version}" to reduce code duplication and because the server automatically redirects http traffic to https. Used "depends_lib-append port:metis" so that a libmetis.dylib located outside the MacPorts prefix does not satisfy the dependency. Used "-dynamiclib" instead of "-shared" when building the dynamic library. Used "universal_variant no" since you're not passing -arch flags to the build, so a universal build doesn't work. Fixed FFLAGS and CC. Passed OSTYPE=darwin to the build so that we don't have to copy darwin.mk to another name. Re-added -faltivec on PowerPC, since the patching of darwin.mk removed it; haven't tested if this actually works on PowerPC or if it maybe still needs vecLib. Added a destroot phase. Probably other changes I've forgotten. It installs for me, and runs, to the extent that the programs can print their help messages; I didn't know how to test them further. \r On Nov 26, 2018, at 19:58, Mark Brethen wrote: > Attached is my current portfile which builds both a static archive and > dynamic library. > > <Portfile><patch-taucs-build.diff> > > The last thing to do is build the example programs that can be used to test > Tarcs: > > #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/|}) > > which corresponds to > > $(DIREXE)direct$(EXEEXT): $(STDDEPS) $(DIROBJ)direct$(OBJEXT) > $(DIRLIB)libtaucs$(LIBEXT) > $(LD) $(LDFLAGS) \ > $(LOUTFLG)$(DIREXE)direct$(EXEEXT) \ > $(DIROBJ)direct$(OBJEXT) \ > -L$(DIRLIB) -ltaucs \ > $(LIBS) > $(DIREXE)taucs_run$(EXEEXT): $(STDDEPS) $(DIROBJ)taucs_run$(OBJEXT) > $(DIRLIB)libtaucs$(LIBEXT) > $(LD) $(LDFLAGS) \ > $(LOUTFLG)$(DIREXE)taucs_run$(EXEEXT) \ > $(DIROBJ)taucs_run$(OBJEXT) \ > -L$(DIRLIB) -ltaucs \ > $(LIBS) > $(DIREXE)iter$(EXEEXT): $(STDDEPS) $(DIROBJ)iter$(OBJEXT) > $(DIRLIB)libtaucs$(LIBEXT) > $(LD) $(LDFLAGS) \ > $(LOUTFLG)$(DIREXE)iter$(EXEEXT) \ > $(DIROBJ)iter$(OBJEXT) \ > -L$(DIRLIB) -ltaucs \ > $(LIBS) > > in the makefile. They set a nonexistent directory using OBJDIR with BSD make. > Gnu make does not have this option, does it? It seems rediculus to have to > build the library each time. Can I issue these with ‘system', omitting the > library object? > > > Mark Brethen > mark.bret...@gmail.com > > > >> On Nov 26, 2018, at 11:45 AM, Ryan Schmidt <ryandes...@macports.org> wrote: >> >> >> >> On Nov 26, 2018, at 10:51, Mark Brethen wrote: >> >>> On Nov 26, 2018, at 10:39 AM, Ryan Schmidt wrote: >>> >>>> 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. >>> >>> You are referring to the $(PICFLAG) variable in the second build? >> >> Yes. >> >>> I wondered about that, and had read that it wasn’t necessary for Mac OSX? >> >> Yes. PIC is on by default on macOS. >> >
