A couple of remaining thoughts I had: 1. The BSD port uses metis4 whereas macports metis distro is at v5. I didn’t check to see which one it used. If it builds alright, I assume it will work.
2. Calculix-ccx requires taucs at build. Should it matter if the static library exists, or not? Thanks! > On Nov 27, 2018, at 4:18 PM, Ryan Schmidt <ryandes...@macports.org> wrote: > > 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. >>> >> >
