vaucanson 2

[akimd (Akim Demaille)]

Hi,

I would like to submit an initial Portfile for Vaucanson 2, a platform to manipulate automata and transducers.

[ryandesign (Ryan Carsten Schmidt)]

Thanks. Some observations:

• Isn't this a beta version? We usually want ports to be for stable versions.
• The "epoch 1" line should be removed; the epoch should start at 0. Most ports never need to increase the epoch.
• The two "installs_libs yes" lines should be removed; that's the default.
• "configure.args CXXFLAGS=-O3" should be removed. MacPorts already sets CXXFLAGS in the environment at configure time. If you're sure you want to change them, change configure.cxxflags. If you just want to change the optimization flags, change configure.optflags, but only if you're sure the default and preferred value of "-Os" doesn't work.
• Why set "configure.compiler macports-gcc-4.8"? If the compilers MacPorts chooses by default don't work for vaucanson, please explain.

[akimd (Akim Demaille)]

Replying to ryandesign@…:

Hi!

Thanks. Some observations:

• Isn't this a beta version? We usually want ports to be for stable versions.

Well, it's the kind of project that remains as "beta" for years before everybody agrees to make it officially "2.0". But it's already functional, and used (albeit by a small community, granted, but that's also because its main users are not so good at "configure && make" etc.).

• The "epoch 1" line should be removed; the epoch should start at 0. Most ports never need to increase the epoch.

Thanks.

• The two "installs_libs yes" lines should be removed; that's the default.

Thanks twice.

• "configure.args CXXFLAGS=-O3" should be removed. MacPorts already sets CXXFLAGS in the environment at configure time. If you're sure you want to change them, change configure.cxxflags. If you just want to change the optimization flags, change configure.optflags, but only if you're sure the default and preferred value of "-Os" doesn't work.

Wow, -Os is the default??? I'm surprised it is not -O2. I don't want to reopen a debate that already happened, but really, that's disturbing. ("All the kids are doing it." -- well, what kids???).

In the current case, toolsets such as Vaucanson are designed to work with automata which can have hundreds of thousands states or transitions, and there -O2 vs. -O3 does make a difference.

However, if preferred I can try to install a variant for this.

• Why set "configure.compiler macports-gcc-4.8"? If the compilers MacPorts chooses by default don't work for vaucanson, please explain.

It is written in C++11. GCC 4.7 cannot compile it, and actually because of various issues (in GCC, not in Vaucanson), the current 4.9 cannot either.

Clang 3.3 and 3.4 work though.

[ryandesign (Ryan Carsten Schmidt)]

Replying to akim.demaille@…:

• "configure.args CXXFLAGS=-O3" should be removed. MacPorts already sets CXXFLAGS in the environment at configure time. If you're sure you want to change them, change configure.cxxflags. If you just want to change the optimization flags, change configure.optflags, but only if you're sure the default and preferred value of "-Os" doesn't work.

Wow, -Os is the default??? I'm surprised it is not -O2. I don't want to reopen a debate that already happened, but really, that's disturbing. ("All the kids are doing it." -- well, what kids???).

MacPorts switched the default optimization flags from -O2 to -Os in version 2.2 because it is what Apple uses to compile the rest of OS X. Comments / complaints / discussion about this should be directed to the macports-devel mailing list where you'll have a greater audience than the handful of people who happen to be reading this ticket. There wasn't much discussion before; Jeremy H S said we should change it, I respect Jeremy's opinion based on prior excellent work and didn't know a reason not to change it, so I changed it. I haven't heard any negative consequences from this change yet.

In the current case, toolsets such as Vaucanson are designed to work with automata which can have hundreds of thousands states or transitions, and there -O2 vs. -O3 does make a difference.

However, if preferred I can try to install a variant for this.

Ok, then feel free to set configure.optflags to -O3. Let's not add a variant.

• Why set "configure.compiler macports-gcc-4.8"? If the compilers MacPorts chooses by default don't work for vaucanson, please explain.

It is written in C++11. GCC 4.7 cannot compile it, and actually because of various issues (in GCC, not in Vaucanson), the current 4.9 cannot either.

Clang 3.3 and 3.4 work though.

Then use the compiler_blacklist_versions portgroup to blacklist the compilers that will not work, and allow MacPorts to select one that does (which will probably be clang).

[ryandesign (Ryan Carsten Schmidt)]

Replying to akim.demaille@…:

• Isn't this a beta version? We usually want ports to be for stable versions.

Well, it's the kind of project that remains as "beta" for years before everybody agrees to make it officially "2.0". But it's already functional, and used (albeit by a small community, granted, but that's also because its main users are not so good at "configure && make" etc.).

We can certainly add this to MacPorts to make it easier for people to install. If version 2 is already working and is preferred over version 1 then this is fine. We could later add a "vaucanson1" port if that becomes desired.

[akimd (Akim Demaille)]

Version 2

[akimd (Akim Demaille)]

Replying to ryandesign@…:

We can certainly add this to MacPorts to make it easier for people to install. If version 2 is already working and is preferred over version 1 then this is fine. We could later add a "vaucanson1" port if that becomes desired.

Hi Ryan,

Please find attached an updated Portfile for Vaucanson 2.

[akimd (Akim Demaille)]

Replying to ryandesign@…:

MacPorts switched the default optimization flags from -O2 to -Os in version 2.2 because it is what Apple uses to compile the rest of OS X. Comments / complaints / discussion about this should be directed to the macports-devel mailing list where you'll have a greater audience than the handful of people who happen to be reading this ticket. There wasn't much discussion before; Jeremy H S said we should change it, I respect Jeremy's opinion based on prior excellent work and didn't know a reason not to change it, so I changed it. I haven't heard any negative consequences from this change yet.

I won't start such a thread :) I am not under the impression that other distros made a similar move, but if there is consensus here, let's proceed.

Thanks!

[akimd (Akim Demaille)]

Ping!

[akimd (Akim Demaille)]

Replying to akim.demaille@…:

Ping!

Ping!

Is there something I can do to help? Thanks in advance.

[ryandesign (Ryan Carsten Schmidt)]

I had to change the master_sites to ​http://www-old.lrde.epita.fr/dload/vaucanson/2.0/ to get the file to download.

You've blacklisted Xcode clang, but the version in Xcode 5.0.1 on Mavericks seemed to build it just fine. So I think you should be more selective and blacklist only those versions of Xcode clang that are unsuitable, using the compiler_blacklist_versions portgroup. XcodeVersionInfo shows the versions of Xcode clang that we know about. If you know a version of Xcode clang that fails to build it, then we can try to narrow it down from there.

[ryandesign (Ryan Carsten Schmidt)]

I've added the port in r113207, blacklisting clang older than Mavericks'; we can refine it further from there.

How does vaucanson use boost? I see a library dependency declared on boost, but I don't see any files installed by vaucanson actually linking with any boost libraries.

[ryandesign (Ryan Carsten Schmidt)]

The build failed on all three buildbots because bison was not new enough so I added a bison build dependency. That fixed the build on Lion and Mountain Lion but Snow Leopard is failing with this log: ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/22196/steps/compile/logs/stdio

[akimd (Akim Demaille)]

Replying to ryandesign@…: Hi Ryan,

I had to change the master_sites to ​http://www-old.lrde.epita.fr/dload/vaucanson/2.0/ to get the file to download.

That's weird. The original link seems to work just as well as this one. What failure did you face?

You've blacklisted Xcode clang, but the version in Xcode 5.0.1 on Mavericks seemed to build it just fine. So I think you should be more selective and blacklist only those versions of Xcode clang that are unsuitable, using the compiler_blacklist_versions portgroup. XcodeVersionInfo shows the versions of Xcode clang that we know about. If you know a version of Xcode clang that fails to build it, then we can try to narrow it down from there.

I need clang 3.3 or better, but on my machine "clang" is 3.2. How can I fine tune by compiler black-list to be sure that when I accept clang, it's really 3.3 or newer? I thought this was globbing on compiler names, but is it better than that? I had written:

# We need C++11 support, provided by G++ 4.8+ and Clang++ 3.3+.
compiler.blacklist  cc \
                    *dragonegg* \
                    *clang \
                    *clang-2.* \
                    {*clang-3.[012]} \
                    *gcc \
                    *gcc-3.* \
                    {*gcc-4.[0-7]}

If I read correctly your answer, this should suffice?

# We need C++11 support, provided by G++ 4.8+ and Clang++ 3.3+.
compiler.blacklist  *dragonegg* \
                    *clang-2.* \
                    {*clang-3.[012]} \
                    *gcc-3.* \
                    {*gcc-4.[0-7]}

Thanks for the detailed answers.

[akimd (Akim Demaille)]

Replying to akim.demaille@…:

Replying to ryandesign@…:

I had to change the master_sites to ​http://www-old.lrde.epita.fr/dload/vaucanson/2.0/ to get the file to download.

That's weird. The original link seems to work just as well as this one. What failure did you face?

Scratch that, our sysadmin now understands what was the trouble (probably related to our auto-signed certificate). It should work more smoothly now.

[akimd (Akim Demaille)]

Replying to ryandesign@…:

I've added the port in r113207, blacklisting clang older than Mavericks'; we can refine it further from there.

That's great, thanks a lot!

How does vaucanson use boost? I see a library dependency declared on boost, but I don't see any files installed by vaucanson actually linking with any boost libraries.

Actually it depends on the compiler that is used. GCC 4.8's support for Regex is too weak, in that case we use Boost's Regex. In the case of Clang, libc++'s Regex is good enough, in which case no Boost library is used, everything is only compile-time dependencies.

[ryandesign (Ryan Carsten Schmidt)]

Replying to akim.demaille@…:

I had to change the master_sites to ​http://www-old.lrde.epita.fr/dload/vaucanson/2.0/ to get the file to download.

That's weird. The original link seems to work just as well as this one. What failure did you face?

Can't reproduce it now! :)

I need clang 3.3 or better, but on my machine "clang" is 3.2. How can I fine tune by compiler black-list to be sure that when I accept clang, it's really 3.3 or newer? I thought this was globbing on compiler names, but is it better than that?

Yes, compiler.blacklist operates on MacPorts compiler names. The MacPorts compiler name of Xcode's clang is always "clang" regardless of what version it is, hence the problem. That's why we wrote the compiler_blacklist_versions portgroup to let you blacklist on a finer grain, based on the version number of the compiler. Note that Xcode's clang is Apple's LLVM compiler, which is based on the open source clang, but does not use the same version numbers. In r113207 I already included this portgroup to blacklisting Xcode clang versions older than Apple's build number 500, which is what Xcode 5 includes. Perhaps slightly older versions of Xcode clang might work also and we can amend this directive if so.

[akimd (Akim Demaille)]

[duplicate comment removed]

[akimd (Akim Demaille)]

Replying to ryandesign@…:

The build failed on all three buildbots because bison was not new enough so I added a bison build dependency.

Great, thanks!

That fixed the build on Lion and Mountain Lion but Snow Leopard is failing with this log: ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/22196/steps/compile/logs/stdio

I can't understand what the problem is without an access to the generated config.log file. How can I get it?

[ryandesign (Ryan Carsten Schmidt)]

Replying to akim.demaille@…:

That fixed the build on Lion and Mountain Lion but Snow Leopard is failing with this log: ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/22196/steps/compile/logs/stdio

I can't understand what the problem is without an access to the generated config.log file. How can I get it?

We don't have access to the filesystems of the buildbots; we'd have to find another Snow Leopard machine and try it out ourselves. I can do that later and provide the config.log.

[akimd (Akim Demaille)]

Replying to ryandesign@…:

I can't understand what the problem is without an access to the generated config.log file. How can I get it?

We don't have access to the filesystems of the buildbots; we'd have to find another Snow Leopard machine and try it out ourselves. I can do that later and provide the config.log.

Then it'd be really useful in many cases if a failing call to configure could dump its config.log in the log file. I mean, in general, not just this Vaucanson particular case.

[ryandesign (Ryan Carsten Schmidt)]

You can propose that on the macports-dev mailing list if you'd like to start a discussion about it. I can see some problems with that idea, including that some projects run multiple configure scripts, and others use cmake or scons or other build systems.

[akimd (Akim Demaille)]

Portfile for v2b.1

[akimd (Akim Demaille)]

Hi Ryan,

I will submit the proposal on macports-dev, thanks for the suggestion.

I have provided an updated version of the Portfile, for 2b.1. Thanks!

[ryandesign (Ryan Carsten Schmidt)]

I've committed the new version in r113315. Let's call this ticket resolved. If you have further changes to propose, please make a new ticket and attach a unified diff of the portfile, rather than a complete new portfile; this makes it easier to evaluate your changes.