Undefined symbols for architecture x86_64

[Mark Brethen]

More feedback from the developer:

> Supposing that a profile.dat is available in csl/generated-c (as it is when one has fetched from subversion, and it will be in some future snapshots, but is NOT in the files you unpack from the .tar file in the mac snapshot directory unless you may yourself a private very very new one to play with). then the full recipe to build everything is
>  ./configure --with-csl; ./configure --with-psl; make
> 
> That sets up to build all necessary components and regenerate all the things that normally need regenerating.
> 
> profile.dat CAN be created from scratch but you will not want to do that.
> 

Is it possible to issue more than one configure statement before make in a port file?


Sent from my iPhone

> On Sep 18, 2018, at 8:32 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> 
> 
>> On Sep 18, 2018, at 08:25, Mark Brethen wrote:
>> 
>> Yep, here is his response:
>> 
>>> Aha - when I look at your macports log you do not seem to be fetching Reduce from subversion, you are fetching a source .tar file for it. Well that has not up to now contained profile.dat because one can regenerate what is needed by going (in a build directory where csl.img etc get created)
>>> make profile
>>> which first builds bootstrapreduce (twice over probably so that forward refereces get optimised), then runs all the Reduce test scripts using it (and because that is in profiling mod it is slower than a regular test run). Subsequent to that "make c-code" will use the new profile info to recreate generated-c/u*.cpp etc. Those steps make the file in cslbuild/generated-c and so the copy of a prebuilt set from csl/gene4rated-c would be unnecessary. So this is sort of rational but is a consequence of the difference between the way macports is building stuff and my expectations! I think I have just changed things so that maybe csl/generated-c/profile.dat should get included in the tar source file - making it yet bigger! 
>> 
>> I explained that only a single make command is issued when a port is installed (not counting subports). In this particular case those steps he mentions would need to be in the top-level makefile, correct?
> 
> The MacPorts defaults only run a single "make all" in the build phase, that's correct. If you need to run multiple make commands in different directories, you can do that in pre-build or post-build blocks, such as:
> 
> pre-build {
>    system -W ${build.dir} "${build.cmd} profile"
> }
> 
> Or if all of the make targets will be run in the same directory, you can even more simply just list all the targets in build.target:
> 
> build.target profile c-code all
> 
> Normally MacPorts will build the targets in parallel, but since you already disable parallel building for this port, they'll be done sequentially.
> 
> If target all requires that target c-code be run first, and if target c-code require that target profile be run first, those dependencies should be declared by the author in the Makefile so that it happens automatically. Until they do that, you can run the targets manually as above.
> 
>