faustlive-devel: new port

[agraef (Albert Graef)]

This is an amazing graphical frontend to the Faust compiler which makes it easy for new Faust users to try out Faust programs and compile them to the desired target architectures. It uses an embedded Faust compiler based on the LLVM JIT, so no external Faust compiler toolchain or SDK is required. Faust programs can be changed on the fly and the user can instantly listen to the results. So this is an ideal learning tool for anyone who wants to get into Faust.

The very latest Faust2 from git is required to build FaustLive, cf. my update request in ticket #45349 (still open as I write this, so this needs to be committed beforehand).

Ryan, since this is the very first port of a native Aqua application that I've done, it would be nice if you could check whether I've done this correctly. The application installs into /Applications/MacPorts, as mandated by the MacPorts guide, and bundled documentation files go into the usual ${prefix}/share/doc/faustlive-devel. I've tested this port as well as I could and it works fine on Mavericks for me.

The Faust2-related libraries are linked statically, so that neither faust2-devel nor LLVM is needed at runtime. The application also requires Qt; I couldn't make it work with qt5-mac from MP (there are some strange linker errors I don't understand yet, will see whether I can get that sorted out later), so the port depends on qt4-mac for now.

[agraef (Albert Graef)]

faustlive-devel Portfile

[ryandesign (Ryan Carsten Schmidt)]

Thanks! Would you like to co-maintain this with me?

"/Applications/MacPorts" should be changed to "${applications_dir}"

The build fails for me:

../../src/Network/FLServerHttp.cpp:25:10: fatal error: 'jack/net.h' file not found
#include <jack/net.h>
         ^

I do have the jack port installed, but although it provides several headers in a "jack" directory, it doesn't provide that file.

faustlive-devel doesn't declare a dependency on jack. Is it finding jack opportunistically? If jack support is not needed (and does not work), can we disable it?

[agraef (Albert Graef)]

Replying to ryandesign@…:

Thanks! Would you like to co-maintain this with me?

Yes.

"/Applications/MacPorts" should be changed to "${applications_dir}"

Ah, I missed that bit, can you take care of it please?

The build fails for me:

Yes, it seems that this header gets included even though the default build uses CoreAudio and Jack shouldn't be needed. Looks like it worked for me since I got Stéphane Letz' binary Jack package installed somewhere, and port -t either didn't catch that or I missed it. I'll have to look at the sources and/or check back with Sarah Denoux to see whether we can get rid of the header.

I do have the jack port installed, but although it provides several headers in a "jack" directory, it doesn't provide that file.

No, it's an extension which is in Stéphane's Jack2 version. I'm not sure where FaustLive looks for it, though.

faustlive-devel doesn't declare a dependency on jack. Is it finding jack opportunistically? If jack support is not needed (and does not work), can we disable it?

I'll check that in a minute, hold on.

[ryandesign (Ryan Carsten Schmidt)]

Replying to aggraef@…:

Replying to ryandesign@…:

"/Applications/MacPorts" should be changed to "${applications_dir}"

Ah, I missed that bit, can you take care of it please?

Sure, I've already done this, and some other changes locally. I noticed a number of bugs in the build process which I'm patching; I can either include those in the portfile when I commit it or attach them here or send them to you if you want to work with the developers to incorporate them upstream.

[agraef (Albert Graef)]

Yeah, turns out that this include isn't needed at all. Without it the module compiles just fine if Jack isn't installed. I've committed this fix upstream now.

With that out of the way, we can now also build a fully Jack-enabled version of FaustLive by linking against the jack1 port in MacPorts. I'll implement this as a variant. Please hold on while I'm updating the Portfile.

NB: NetJack support isn't possible for now since it isn't available in MacPorts, but that's all right, we can add that at a later time when the dependencies are there. (This is needed for some of FaustLive's really fancy features which enable you to redirect sound to another machine on the network while the Faust program keeps running. Amazing stuff.)

[agraef (Albert Graef)]

Replying to ryandesign@…:

Sure, I've already done this, and some other changes locally. I noticed a number of bugs in the build process which I'm patching; I can either include those in the portfile when I commit it or attach them here or send them to you if you want to work with the developers to incorporate them upstream.

Please toss them my way, I might just as well commit them while I'm at it.

[agraef (Albert Graef)]

I have a new Portfile with the Jack variant ready, should I just attach it here or do you prefer diffs against the previous one? The changes are rather trivial:

updated hash:

git.branch              f18900b9c2c5a247ed139c356293c22c5e755803

jack variant:

variant jack description {Enable Jack support} {
    depends_lib-append  port:jack
    build.args-append   JACK=1
}

I just tested this here, works fine also with Stéphane's Jack2 package.

[agraef (Albert Graef)]

Updated Portfile (+latest from git, Jack variant).

[ryandesign (Ryan Carsten Schmidt)]

Replying to aggraef@…:

I have a new Portfile with the Jack variant ready, should I just attach it here or do you prefer diffs against the previous one?

Thanks. For new ports, we want complete Portfiles; for existing ports, we want unified diffs.

[ryandesign (Ryan Carsten Schmidt)]

...although I do appreciate you telling me what you changed since that makes it easier to apply your changes to my local already-modified portfile.

You've declared faust2-devel as a build dependency, and I see that the build system copies faust2-devel's sound2faust program into FaustLive.app's Contents/MacOS directory. This means every time faust2-devel is updated, we have to have everyone rebuild faustlive-devel as well. To avoid that, I would rather have a sound2faust symlink in the Contents/MacOS directory and make faust2-devel a library dependency. Any objections to that?

[agraef (Albert Graef)]

Replying to ryandesign@…:

You've declared faust2-devel as a build dependency, and I see that the build system copies faust2-devel's sound2faust program into FaustLive.app's Contents/MacOS directory. This means every time faust2-devel is updated, we have to have everyone rebuild faustlive-devel as well. To avoid that, I would rather have a sound2faust symlink in the Contents/MacOS directory and make faust2-devel a library dependency. Any objections to that?

No, I wouldn't do that. The idea of FaustLive (and one of its major design goals) is precisely that it is self-contained and *can* be run independently from the full faust2 compiler toolchain. That's why the port pushes faust2-devel into the build dependencies, includes its own sound2faust executable (which doesn't depend on any of the Faust libraries, only on libsndfile and friends) and links against libfaust and the other Faust libraries statically. So, in principle, once the package has been built and installed, it can be run alongside any Faust version or without any Faust installation at all.

Consequently, there's no need to rebuild faustlive-devel if faust2-devel changes, although faust2-devel is needed to build faustlive-devel. In fact it's the opposite: A specific git revision of faustlive usually depends on a specific faust2 git revision (typically the one that's current at the time the faustlive snapshot is taken).

So we should really make the specific MP version of faust2-devel needed to build a given MP version of faustlive-devel a build dependency of that version. But I'm not sure how to do that in a MP Portfile; the MP guide doesn't mention a syntax of port: dependency for requiring a specific version of the dependency. Unfortunately libfaust.a from faust2 doesn't carry a version number right now, so a lib: dependency doesn't help either.

I hope that I explained that well enough. The bottom line is that faust2-devel intentionally is a build time dependency only and that, if possible, a specific version of faustlive-devel should be made to depend on a specific faust2-devel version in its build dependencies.

[ryandesign (Ryan Carsten Schmidt)]

Replying to aggraef@…:

So we should really make the specific MP version of faust2-devel needed to build a given MP version of faustlive-devel a build dependency of that version. But I'm not sure how to do that in a MP Portfile; the MP guide doesn't mention a syntax of port: dependency for requiring a specific version of the dependency.

MacPorts does not have this capability. MacPorts will always install the current version of a port; there is no way to request or receive a different version. If specific versions of faustlive-devel depend on specific versions of faust2-devel, then the updates to both ports must be coordinated and simultaneous.

[agraef (Albert Graef)]

Replying to ryandesign@…:

MacPorts does not have this capability. MacPorts will always install the current version of a port; there is no way to request or receive a different version. If specific versions of faustlive-devel depend on specific versions of faust2-devel, then the updates to both ports must be coordinated and simultaneous.

Fair enough. I'll take care of that.

[ryandesign (Ryan Carsten Schmidt)]

And we want deterministic repeatable builds. Imagine this scenario:

• on 20141015 we update faust2-devel to version 20141015
• on 20141016 we update faustlive-devel to version 20141016 which is compatible with faust2-devel 20141015
• on 20141017 user X installs faustlive-devel 20141016 and gets a working port
• on 20141018 we update faust2-devel to version 20141018 which is not compatible with faustlive-devel 20141016 anymore
• on 20141019 user Y installs faustlive-devel 20141016 and gets a non-working port; user X's installation still works fine

We don't want two different users installing the same version of a package to have different results, which is why embedding another port's files is usually undesirable and why I would use a symlink instead.

[agraef (Albert Graef)]

So will MacPorts always trigger a rebuild of faustlive-devel when faust2-devel is updated, even if an update of faustlive-devel is not strictly necessary? Then I guess that we'll just have to live with that.

I'd still like to keep faust2-devel as a build time dependency only, so that the user can easily change the Faust version, or just remove the CLI compiler after installing faustlive. In fact that's something that I do myself so frequently that it would be very annoying to have faust2-devel as a runtime dependency, forcing me to uninstall or deactivate faustlive-devel every time I change the Faust version on my system.

[agraef (Albert Graef)]

Replying to ryandesign@…:

We don't want two different users installing the same version of a package to have different results, which is why embedding another port's files is usually undesirable and why I would use a symlink instead.

But that would make faustlive-devel depend on faust2-devel at runtime, which, as I pointed out above, is highly undesirable. Is there no way that we can avoid that?

[agraef (Albert Graef)]

Hmm, sound2faust is just two files, a Makefile and the C++ source. We might include those in the port and just build sound2faust along with FaustLive. If copying sound2faust is really a problem. I don't see how copying an executable from a build time dependency is much different from linking against libfaust statically, though. This kind of thing ought to be possible, no?

[ryandesign (Ryan Carsten Schmidt)]

I don't think I quite understand why the runtime dependency is undesirable.

Are you saying that you want to be able to install faustlive-devel (which needs faust2-devel), and then deactivate faust2-devel and use faust or faust-devel for other purposes while still being able to use faustlive-devel?

[agraef (Albert Graef)]

Yes, I see what you mean. But sound2faust then is the least of our concerns. Statically linking against libfaust, libOSCFaust and libHTTPDFaust is a much more serious problem in your scenario, since these are much more likely to change between faust2 revisions, potentially making faustlive-devel's behavior depend on the particular faust2-devel version it was built with.

But keeping faust2-devel out of faustlive-devel's runtime dependencies is really important. It's so important for me that I'd rather keep updating both ports in lockstep. Hence my question whether MP actually enforces an upgrade of a port when one of its build dependencies is updated.

Replying to ryandesign@…:

And we want deterministic repeatable builds. Imagine this scenario:

• on 20141015 we update faust2-devel to version 20141015
• on 20141016 we update faustlive-devel to version 20141016 which is compatible with faust2-devel 20141015
• on 20141017 user X installs faustlive-devel 20141016 and gets a working port
• on 20141018 we update faust2-devel to version 20141018 which is not compatible with faustlive-devel 20141016 anymore
• on 20141019 user Y installs faustlive-devel 20141016 and gets a non-working port; user X's installation still works fine

We don't want two different users installing the same version of a package to have different results, which is why embedding another port's files is usually undesirable and why I would use a symlink instead.

[ryandesign (Ryan Carsten Schmidt)]

MacPorts does not automatically upgrade a port when one of its build dependencies is updated; we would manually increase faustlive-devel's revision every time faust2-devel is updated to accomplish that.

[ryandesign (Ryan Carsten Schmidt)]

You're right, the static linking would be a problem in that scenario as well. We don't like static linking either for that reason.

[agraef (Albert Graef)]

Replying to ryandesign@…:

I don't think I quite understand why the runtime dependency is undesirable.

Are you saying that you want to be able to install faustlive-devel (which needs faust2-devel), and then deactivate faust2-devel and use faust or faust-devel for other purposes while still being able to use faustlive-devel?

Yes, exactly!

[agraef (Albert Graef)]

Replying to ryandesign@…:

You're right, the static linking would be a problem in that scenario as well. We don't like static linking either for that reason.

Me neither in principle, but then I wouldn't be able to mix faustlive-devel with faust, faust-devel or no Faust installation at all. Those use cases are important, and I don't see any other way of doing it, as faust1 and faust2 can't be installed at the same time.

[ryandesign (Ryan Carsten Schmidt)]

I had assumed that faust2-devel, being the latest version, was a superset of all faust functionality, above and beyond faust and faust-devel, and that if you have faust2-devel installed there would be no reason to go back to faust and faust-devel.

Or is faust 2 incompatible with faust 1 in some way?

What will happen when faust 2 becomes the new stable version? Will we retire the faust2-devel port and update the faust port to version 2, or will we create a new faust2 port and keep it updated in parallel with the faust port which would stay at version 1?

Because if the goal is to continue to keep both faust 1 and 2, then they should install their files to different locations and not conflict with one another like they currently do. And then there will be no problem for your scenario.

[agraef (Albert Graef)]

Replying to ryandesign@…:

I had assumed that faust2-devel, being the latest version, was a superset of all faust functionality, above and beyond faust and faust-devel, and that if you have faust2-devel installed there would be no reason to go back to faust and faust-devel.

Faust is an ongoing research project. faust1 is considered stable, while faust2 is experimental, the next generation of Faust where new ideas from research are incorporated. So faust1 offers a much more limited but stable feature set sufficient for supporting most Faust applications, while faust2 can occasionally be broken in some (relatively minor) ways but is the only way to support more sophisticated applications like FaustLive right now.

This means that most users will use faust1 for regular development, but we'd still like to use FaustLive (which depends on faust2) for teaching, and faust2 itself for more advanced applications like running Faust dsps at near-native speed in JavaScript in a browser, so both must be available.

Or is faust 2 incompatible with faust 1 in some way?

The Faust language supported by both implementations is the same, but under the hood there are many differences which may result in different native code to be generated.

What will happen when faust 2 becomes the new stable version?

Then most likely faust1 will go the way of the dodo, and faust2 will be the new faust, and we'll just have to maintain a single port (or two of them, to also track the latest development version). But I don't expect that to happen anytime soon.

Because if the goal is to continue to keep both faust 1 and 2, then they should install their files to different locations and not conflict with one another like they currently do. And then there will be no problem for your scenario.

Yes, but I don't see that happening anytime soon either, as far as upstream is concerned. We could probably use some special installation prefixes in the ports, but that's not nice from the usability standpoint either. We need a practical solution. What would you suggest? What about putting faustlive-devel in the binary package repositories? Wouldn't that solve most problems?

[ryandesign (Ryan Carsten Schmidt)]

All ports are automatically made available as binaries, if the combination of all the licenses used allows it.

I'll go with your original suggestion for now, and we can see if it works ok or if we need to change it later.

[agraef (Albert Graef)]

Great, many thanks.

The latest upstream revision right now is cf971dd which seems to have some further bugfixes in the GUI, so if it's still possible it would be nice if the port could be updated to that revision. It identifies itself as FaustLive 2.24, so the version information would be:

version                 2.24-20141014
git.branch              cf971dd7eb230259b6376183a28a0ce1d8d2334e

I just tested the port with that revision, works fine over here.

[agraef (Albert Graef)]

Latest revision now:

version                 2.27-20141017
git.branch              75b76ea4983174d340d568d27fc434603acd6663

This has some further improvements in the GUI, especially the scrollbars in the dsp window (which is quite essential given that many Faust programs have lots of controls which didn't fit into the dsp window before).

This goes along with another update of the faust2-devel port (build dependency), cf. ticket #45454.

I'm attaching my latest version of the Portfile.

Ryan, are there any further issues with this port that you'd like to discuss? Otherwise could you please commit it? Lectures start next week and I'd really like to have this port ready for the students by then. If you're too busy right now, maybe you could hand it over to someone else with commit rights?

[agraef (Albert Graef)]

Updated Portfile

[agraef (Albert Graef)]

Latest version of Portfile, with /Applications/MacPorts changed to ${applications_dir}, as you recommended. I'm not sure what the other local changes you mentioned are, so you may have to reapply these.

[agraef (Albert Graef)]

Just found and fixed another bug upstream (dsp window sizes were not remembered). The latest version is now:

version                 2.27-20141019
git.branch              bb05751b3a6268bd08aebb57153aa11e17e3a871

Updated Portfile attached.

[agraef (Albert Graef)]

Latest Portfile

[ryandesign (Ryan Carsten Schmidt)]

Sorry for the delay, I was sidetracked with Yosemite stuff. Port added in r127041.