GNU Automake 1.15.1 Comes After A Stall In The Project

[tuuker]

CMake is best for future and Perl should die already. Systems has to become more optimal and lightweight and less cruft in system can have good benefits in every aspect.

[L_A_G]

Maybe I'm just a luddite, but I've never seen much of a point in moving to CMake or Meson other than to be able to boast about how you've adopted something new and advanced.

If it ain't broke, don't fix it and even the best tools can be a massive pain in the you-know-what if they're used by people who don't know what they're doing.

[cen1]

Maybe I'm just a luddite, but I've never seen much of a point in moving to CMake or Meson other than to be able to boast about how you've adopted something new and advanced.

If it ain't broke, don't fix it and even the best tools can be a massive pain in the you-know-what if they're used by people who don't know what they're doing.

If you ony live in Linux word I guess it is ok, as soon as you need cross platform it's a no brainer.

[stefantalpalaru]

The reason why it stalls is probably because every sane person on the planet now uses CMake..

There's nothing sane about previous command line arguments being cached and reused. For example:

"cmake -DWANT_FOO=ON" has a hidden effect on a future "cmake -DWANT_BAR=ON" - "WANT_FOO" is still enabled even if it no longer appears in the command line.

This is just one of the many drawbacks of CMake, but it should be enough to show that it was designed poorly. I'd rather stick to Autotools, because it's the devil we know and when the going gets tough, those good ol' programs make difficult things possible. Case in point: mixing Go and C files to make a library - https://github.com/stefantalpalaru/g...er/Makefile.am

[Vistaus]

There's nothing sane about previous command line arguments being cached and reused. For example:

"cmake -DWANT_FOO=ON" has a hidden effect on a future "cmake -DWANT_BAR=ON" - "WANT_FOO" is still enabled even if it no longer appears in the command line.

This is just one of the many drawbacks of CMake, but it should be enough to show that it was designed poorly. I'd rather stick to Autotools, because it's the devil we know and when the going gets tough, those good ol' programs make difficult things possible. Case in point: mixing Go and C files to make a library - https://github.com/stefantalpalaru/g...er/Makefile.am

Also, if I try to build something with CMake and it complains about something and I fix it, then I usually have to go all the way and remove CMakeCache.txt With Meson (and even autotools), I don't have to remove any stupid cache file. Meson is even more awesome 'cause even when something does change, you don't have to run the config process (meson ..) all over again, you can just go ahead and use ninja -j3 directly. That also shows that CMake is poorly designed because it caches everything.

And mind you that I'm not even a developer but an end user who likes to compile stuff for test purposes (e.g. latest Corebird from Git Master, latest budgie-desktop from Git Master, etc.).

[AndyChow]

Code is not like math. A math expression is usually 100% independent from any other, code in modern complex programs (and most older complex ones too) is interconnected to other code that isn't standing still.

Failure to keep your project up-to-date with the changes means it's bitrotting, eventually reaching a stage where it can't be used in a modern system anymore because all the other stuff is too different and it can't interact with it.

It actually is, very much so, in it's definition as a basic description. Code and computing is an automorphic algebra of a Turing machine on itself.

Code, like C, should floats over the machine. It is(should) be architecture independent. And never rot, except the headers.

I know you smart guys are smarter than the basics (and me), but there is a reason most banking transactions run on Fortran 77. If the +/- transaction worked then, it works now (ignore machine epsilon). It doesn't rot. It's always special tricks that run so much faster, and rot, and cause trouble.

True code is a mathematical abstraction, and does not become obsolete.

[starshipeleven]

It actually is, very much so, in it's definition as a basic description. Code and computing is an automorphic algebra of a Turing machine on itself.

"Code" does not mean "it never rots ever", and please don't technobabble me with bullshit like "automorphic algebra of stuff".

Code, like C, should floats over the machine. It is(should) be architecture independent. And never rot, except the headers.

The issue is if your program has to talk to other programs, and has to run in an OS. That isn't a program that runs alone. It relies on other stuff, and there is code in your program to do this interfacing.

Because you will have to write code to do that, and as the programs change then that code will not work anymore as the programs it was supposed to work with don't accept that kind of input anymore.

Or libraries, same thing.

I know you smart guys are smarter than the basics (and me), but there is a reason most banking transactions run on Fortran 77.

Even assuming it is true (citation needed), then it would be that it's easier to maintain an older codebase than rewrite it from scratch, as you just need to change the code that allows your program to interface itself with the other programs to keep it functional.

They still hire Fortran programmers, guess why.

True code is a mathematical abstraction, and does not become obsolete.

you are confusing code with algorithm, and adding bullshit because the algorithm isn't necessarily math.

The algorithm is pure logic and/or math so it should not become obsolete unless its premises are found invalid somehow.

The code is just how you write down the algorithm in a way that a program (the compiler) can create an executable program out of it, and contains all details about interfacing with the actual real world and stuff, and these technical details need maintenance.