faust-devel, faust2-devel: update to latest git source

[agraef (Albert Graef)]

I've updated these to the latest git revisions and added some optional libraries and utilities needed by more advanced Faust applications like FaustLive (which I plan to port as well). I also worked with upstream to make make dynamic work, so that the dylib versions of the libraries (libfaust, libHTTPDFaust and libOSCFaust) are now also included.

Notes:

• There are some new runtime dependencies due to upstream changes and the added libraries and utilities.

• I had to disable parallel builds to make make httpd dynamic work, which might otherwise try to build identical targets at the same time. If anyone has an idea how to serialize these subtargets without disabling parallel make altogether, please let me know; I couldn't find anything in the GNU make documentation.

I've attached both the diffs against the current Portfiles, and the updated Portfiles themselves. It would be nice if someone could commit these. Thanks.

[agraef (Albert Graef)]

faust-devel Portfile changes

[agraef (Albert Graef)]

faust2-devel Portfile changes

[agraef (Albert Graef)]

faust-devel Portfile

[agraef (Albert Graef)]

faust2-devel Portfile

[agraef (Albert Graef)]

Concerning the serialization of the httpd and dynamic subtargets, it just came to me that a custom build command like make all httpd sound2faust && make dynamic would probably do the trick.

[mf2k (Frank Schima)]

Thanks. In the future, we only need the diffs.

[agraef (Albert Graef)]

So can someone please commit this? My courses start in two weeks, and I still need to add a port for the FaustLive package.

[larryv (Lawrence Velázquez)]

Generally, if a ticket has stalled, you should post to macports-dev to try getting a committer’s attention.

[ryandesign (Ryan Carsten Schmidt)]

I am looking into it right now.

[ryandesign (Ryan Carsten Schmidt)]

I did not actually encounter a build failure when using parallel building. Did you? If so could you attach the main.log file?

[agraef (Albert Graef)]

Replying to ryandesign@…:

I did not actually encounter a build failure when using parallel building. Did you? If so could you attach the main.log file?

No, I didn't, but I think that in principle it's possible by looking at the Makefile, so I decided to play it safe. The problem is with make dynamic. I really think that this should be executed separately after all the other targets, since otherwise it will invoke a submake which will try to build some of the same targets that make all and make httpd will try to build, too. It's hard to see whether that's actually a problem in practice, however.

[ryandesign (Ryan Carsten Schmidt)]

On second thought, I do see the problem.

Maybe MacPorts base should automatically run the build phase multiple times, once for each build.target, to avoid this problem.

Updated faust-devel in r126287 and faust2-devel in r126288.

I had to apply numerous patches to fix hardcoded compiler invocations in the makefiles. I also had to override the architecture choices the makefiles made.

[larryv (Lawrence Velázquez)]

Replying to aggraef@…:

The problem is with make dynamic. I really think that this should be executed separately after all the other targets, since otherwise it will invoke a submake which will try to build some of the same targets that make all and make httpd will try to build, too. It's hard to see whether that's actually a problem in practice, however.

The correct way to fix this would be to patch the makefile so that the “dynamic” target depends on whichever other targets need to run first.

[ryandesign (Ryan Carsten Schmidt)]

It doesn't already? That would indeed be a bug in faust. Sorry I didn't check for that; I was just tired of looking at this port due to all the other problems I already dealt with.

[larryv (Lawrence Velázquez)]

Replying to ryandesign@…:

It doesn't already?

I haven’t looked myself; I’m just assuming that the dependencies aren’t declared properly. Note that GNU Make ​processes goals in the order provided on the command line. Thus, make A B C will handle goal “A”, then “B”, then “C”, in turn. I don’t know whether other Make variants behave similarly, but we can easily force GNU Make:

build.type gnu
build.target-append httpd foo bar baz dynamic

This would have no parallel build issues and would obviate the need for the post-build song and dance.

[ryandesign (Ryan Carsten Schmidt)]

GNU make is used by default; build.type gnu should change nothing.

[larryv (Lawrence Velázquez)]

Replying to ryandesign@…:

GNU make is used by default; build.type gnu should change nothing.

Doesn’t look like it is​. Not in all cases, anyway, although I think on most (all?) systems we support, make is GNU Make, so we can assume the use of GNU Make in practice.

In any case, simply listing “dynamic” last in build.targets is entirely sufficient.

[agraef (Albert Graef)]

The dependencies are declared properly in the sub-Makefiles. But the toplevel Makefile has just phony targets which invoke some submakes. That design is very usual. The phony targets don't depend on each other, however, so I'm not sure whether a parallel make won't just go off and invoke them all at the same time. I think that GNU make does that, too, but I might be wrong.

Ryan, thanks for committing the ports, I really appreciate all the work that you put into this.

[larryv (Lawrence Velázquez)]

Replying to aggraef@…:

I think that GNU make does that, too, but I might be wrong.

Hm. The documentation is admittedly unclear on this, and briefly perusing the GNU Make source code was not enlightening.

That said, we could still patch the phony targets to have the desired dependencies.

[larryv (Lawrence Velázquez)]

Sorry for the noise. Turns out that the documentation doesn’t describe the behavior very well: Specifying the goals on the command line simply adds them (in order) to the list of targets to be run, so parallel building behavior applies to them as usual.

% >test.makefile <<EOF
heredoc> .PHONY: foo bar baz
heredoc> 
heredoc> foo:
heredoc>        @echo foo start!
heredoc>        @sleep 10
heredoc>        @echo foo end!
heredoc> 
heredoc> bar:
heredoc>        @echo bar start!
heredoc>        @sleep 5
heredoc>        @echo bar end!
heredoc> 
heredoc> baz: 
heredoc>        @echo baz start!
heredoc>        @sleep 2
heredoc>        @echo baz end!
heredoc> EOF
% make -f test.makefile foo bar baz
foo start!
foo end!
bar start!
bar end!
baz start!
baz end!
% make -f test.makefile -j 8 foo bar baz
foo start!
bar start!
baz start!
baz end!
bar end!
foo end!
%

I still say that the simplest solution is to patch the targets’ dependencies.

[agraef (Albert Graef)]

Replying to larryv@…:

I still say that the simplest solution is to patch the targets’ dependencies.

You're right. Simply adding baz: foo bar to your example makes sure that GNU make actually waits for foo and bar to finish before starting baz. Sorry, I didn't realize that, otherwise I would have included a corresponding patch for the toplevel Makefile in the first place.

Ryan, I think that it makes most sense if I work with upstream in order to get this fixed (along with the other Makefile issues you encountered), and then submit another update request so that we can do without the patches and the post-build stuff, as larry suggested.

[ryandesign (Ryan Carsten Schmidt)]

Sounds good. I've also filed #45274 to explore the idea of changing base to avoid this kind of problem.