platforms/unix/config/acinclude.m4

 
Hi All,

    wouldn’t we be better off using flat makefiles for Linux platforms like the Mac and Windows which are parameterized with some sort of per-Linux-dialect “available libraries” file, instead of struggling to make this automatic work across platforms?  

If we go this route (and I strongly think we should) then we would have to
- have a way of determining Linux dialects (uname is that means) and some pattern-matching facility to distil the various inane outputs Into names like (I suppose) redhat-6, manjaro-4 etc.
- have files like redhat-6.include in build.linux64x86/common et al that specify clearly what libraries we can expect and could include the package manager commands to make sure prerequisites are loaded

Tobias, it’s heroic of you to fix platforms/unix/config/acinclude.m4, and I appreciate the effort.  But platforms/unix/config/acinclude.m4 makes it extremely hard to ask questions such as “what sound plugins would be built on Linux dialect babel-17?” unless one is actually on Linux dialect babel-17.  IMO we need a declarative solution here.  We waste *huge* numbers of cycles on every Linux build running configured which, fingers crossed, and if one has remembered to install the package prerequisites, always produce the same answers, but those answers are not easily predictable in advance, and unobtainable except on the exact variant in question.  So what we have in the Unix autoconf system is slow opacity; the very opposite of fast clarity.  Why are we still fighting this crap after twenty five years?

_,,,^..^,,,_ (phone)

 
Hi all, hi Eliot

I am strictly opposed to flat makefiles for something as complex as this VM, sorry.
I'd rather go with Ian's CMake design [1]

We cannot predict the configuration of the machines building the VM.
For that, we have autoconf ( :/ ) or CMake.


These can reliably detect
 - what compilers are there and what's their capabilities
 - what libraries are there
 - where are those
 - whether user want to use different libs
 - etc.

I understand we have opposing points of view here, quite obviously.

However, I do not see what the changes I made to better support FreeBSD on one hand
and the sound plugins on the other hand would have looked like in a plain makefile environment.
If anyone can show me that (no need to steal Eliot's time), I'm willing to change my stance,
but I really do not see how makefiles help.
Especially since Windows NMake Linux Gnu Make and BSD Make are different beasts after all.

In that sense, cheers :)
        -Tobias


[1]: I converted a plain-makefile-outgrown-itselft buildsystem for the Self VM to CMake.
     After that, it was easier to trace down the build system, and it also was faster.
     I had evaluated the other players at that time, autoconf, gyp, scons, qmake but
     the net effect was that things wouldn't have become easier; Also, having Xcode projects
     was a must, which only CMake really provided [2]
     (This discussion: https://stackoverflow.com/a/18291580/1197440 still holds)
[2]: I really like that CMake can generate different ways of actually carrying out the build (which autoconf cannot),
     including Xcode project, VisualStudio project, Eclipse project, ninja[3] and various makes
     (see https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html )
[3]: https://ninja-build.org/ is said to be very fast.

PS: Whisky?