fluidsynth: use configure.cc for all components

[MarcusCalhoun-Lopez]

See https://trac.macports.org/wiki/UsingTheRightCompiler

Use configure.cc to build make_tables.exe.
Since make_tables.exe is used but not installed, no revbump.

Description

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS 10.14.2
Xcode 10.1

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL?

• checked your Portfile with port lint?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?

[macportsbot]

Notifying maintainers:
@mojca for port fluidsynth.
@RJVB for port fluidsynth.

[macportsbot]

Travis Build #5157 Passed.

Lint results

--->  Verifying Portfile for fluidsynth
--->  0 errors and 0 warnings found.

Port fluidsynth success on xcode9.4. Log
Port fluidsynth success on xcode8.3. Log
Port fluidsynth success on xcode7.3. Log
Port fluidsynth success on xcode10.1. Log

[mojca]

I would like to push this upstream.
But what about other variables / CMake arguments?

[MarcusCalhoun-Lopez]

Getting all of the CMake arguments to be passed to ExternalProject_Add seems to be nontrivial, at least according to this Stack Overflow answer.
Since the resulting program (make_tables.exe) is only used as part of the build process, perhaps the other MacPorts variable are less important?
We could also create a separate subport for make_tables.exe, but I do not know if it has any use outside of building fluidsynth.

[mojca]

OK, after taking a closer look at https://github.com/FluidSynth/fluidsynth/blob/master/src/gentables/CMakeLists.txt

# remove $CC from the current environment and by that force cmake to look for a (working) C compiler,
# which hopefully will be the host compiler
unset(ENV{CC})

this looks like a deliberate decision. I thought it might be sufficient to comment out the line which unsets CC, but that didn't work for me and in any case I'm not sure what the correct upstream solution could be then, maybe we simply cannot solve that so easy with CMAKE, short of extending CMAKE's functionality itself.

@RJVB: using the correct compiler is part of MacPorts guidelines that allows us to run MP on legacy systems. It might not be important in this case, but what if sources start requiring C18? How would you build them on Tiger then?

I believe it makes sense to merge this. I'm not particularly proud of the way this is worked around either, but I'm short of better ideas.

[RJVB]

If make_tables is only used during the build process, how important is it that it is built using the compiler selected for the components that will ultimately be installed? This is C code so there is no potential libstdc++-vs-libc++ aspect and indeed I don't see a reference to a bug report.

If this is indeed the case, make_tables is a bit like GNU perf, gettext or even cmake or the compiler itself; which compiler is used to build these tools is (a priori) of no consequence for the stuff built using them.

I haven't looked at the code, but if you really think this should be built using the exact same settings it will probably be much easier to sell upstream if you get make_tables to build as a subproject instead of as an external project. IDEs that understand CMake files will then include the make_tables source code as a full part of the project, for instance.
I think this should be possible as long as the utility doesn't have to be run by cmake.

[RJVB]

Setting CMAKE_BUILD_TYPE here is at least as important as setting the compiler. We use a custom build type to make CMake use the CFLAGS & family env. variables which I can more easily imagine as more important than the actual compiler. The generated tables could be different for 32bit vs. 64bit builds for instance.

[RJVB]

this looks like a deliberate decision

Yes, but it beats me why they'd want to do things that way. Sounds like someone should ask (github issue?)...

I thought it might be sufficient to comment out the line which unsets `CC`, but that didn't work for me

Did you at least throw out CMake* in the toplevel build directory to get rid of any caching CMake might be doing? Note that that change indeed may not be sufficient if the make_tables build AND cmake/configure steps are run *after* the initial cmake run, i.e. during `port build`. It shouldn't be (sufficient) if CC is set only during the configure step.

@RJVB: using the correct compiler is part of MacPorts guidelines that allows us to run MP on legacy systems. It might not be important in this case, but what if sources start requiring C18? How would you build them on Tiger then?

I am inclined to say "let's take that bridge when we get there". It's praiseworthy to strive for this kind of thing but by the time the problem presents itself (for this port or any other port) there might be no more users running 10.4 or interested in running the port in question, or there could be any number of other reasons why the software won't build.

I believe it makes sense to merge this. I'm not particularly proud of the way this is worked around either, but I'm short of better ideas.

Just be sure to add the CMAKE_BUILD_TYPE specification. As I said before, the alternative w/could be to add a make_tables target and let the main target depend on it. That way the make_tables build will use the same compiler and arguments as the rest of the build, automatically. But: more work to implement and maintain, if upstream have reason not to want it.

[mojca]

It's praiseworthy to strive for this kind of thing but by the time the problem presents itself (for this port or any other port) there might be no more users running 10.4 or interested in running the port in question

We are not yet at the point where the build fails, but some are still maintaining their own repositories just because they want to run fluidsynth on Tiger:
https://trac.macports.org/ticket/36962#comment:5

[MarcusCalhoun-Lopez]

As has been noted in the upstream report, there does not seem to be a lot of enthusiasm for this patch.
@kencu is advocating for the "keep it simple" approach.

However, just as a side note, the current situation is slightly inconvenient for those of us who have set up our machines in "[h]ow to test" mode.
This is how I came across this issue in the first place.
Yes, we can revert this setup, install/upgrade fluidsynth, and then reapply.
It is just a tiny inconvenience.

[kencu]

Agreed -- at the moment, there is no upstream enthusiasm for changing this, so no point banging our heads against the wall.

[kencu]

But we can certainly fix it in MacPorts if we choose to do so.

[RJVB]

Indeed, there's even some hostility upstream to the idea of changing things here. Maybe a mod that introduces control over the compiler used will have more success, but just as maybe we ought to wait with that until the build actually starts failing. Meanwhile the portfile could probably circumvent issues with this testing mode I'd never heard of before (and frankly don't get as something you'd want to have on permanently; sounds more like something for a CI system or the build bots). But among the arguments in favour of control over the compiler I also saw "building PPC binaries on Intel". That's a situation where you probably do NOT want to use the same compiler as the one used for fluidsynth itself, unless you happen to be running on 10.6 or earlier? Kind of stupid that they don't want to use an interpreted language to generate the necessary tables because that would add a dependency. I didn't go over the list of tickets and/or other kinds of exchanges they referenced as justification for not reopening that discussion. Could be worth it to have a look if there is no pointer to a working python implementation in there, which we might be able to use. Another way around this: the port maintainers could simply generate the table(s) and ship them through $filespath. In that case the patch would be to yank the external build thing from the cmake files. A bit more work for us but if those tables are indeed platform-agnostic it should be the better solution according to the reproducible build dogma...

[kencu]

Winning a point lasts a minute, but losing a friend is forever. The internet is so impersonal.

[RJVB]

Something I remembered because I saw it popping up elsewhere: there's always the possibiltity to set up the configure and build environments in such a way that CMake finds exactly the compiler we want via its default search mechanism. That could be using a wrapper script if we need to control the arguments. I've used that approach to get a newer-than-officially-supported Qt 5 to build on OS X 10.6 ; the implementation should be a whole lot simpler here even if changing PATH from a Portfile isn't entirely trivial.

[mojca]

Lacking a better idea I'll merge this. I would prefer to find a better way: the sooner we find it the better, but it's now already two people who had issues updating this port and had to do workarounds, and it makes no sense to accumulate open PRs forever.