@pinskia Idiot noob question about the Makefile.am in libstdc++-v3 --

[malwareminigun@infosec.exchange]

@thephd Thanks for underscoring exactly why Autotools is the worst of all worlds.

Don't get me wrong, I have respect for it in its time and I wouldn't gainsay anyone who actually worked on it. But in the modern era it's just awful.

[diegovsky@bolha.us]

@malwareminigun @thephd

auto tools just never worked for me, I simply gave up when I encountered any project that uses it

at this point find + xargs + gcc might just be better fr

[malwareminigun@infosec.exchange]

@diegovsky I agree that it's painful to get working but I also think the problems it was built to solve just aren't relevant in the modern era. I care about Windows, Linux, and macOS. I don't care about 40 different proprietary Unixes. Autotools is built to deal with the latter.

[diegovsky@bolha.us]

@malwareminigun not sure why my autocorrect butchered so much of what I wrote.

in any case, I totally agree!

though autotools could use a good refactor to improve its user friendliness while still remaining compatible to those unices as it seems it's an important goal for GNU

[malwareminigun@infosec.exchange]

@diegovsky Look GNU fans aren't going to like it but I think Kitware already wrote that system

[uecker@mastodon.social]

@malwareminigun @diegovsky I hate autotools, but I think Cmake is worse.

[malwareminigun@infosec.exchange]

@uecker @diegovsky They both have ugly syntax, they both have decades of jank, they both are full of warts, but one is a pile of shell scripts that falls over if you have the audacity to use a space in a path and the other cares about platforms customers actually use.

I'm not saying I love CMake. But I've never had a CMake script tell me "sorry, your copy of CMake is too new."

[uecker@mastodon.social]

@malwareminigun @diegovsky Just anecdotal, but CMake wasted a lot more of my time trying to fix random build errors that provide no useful information about what is actually wrong. Whether is actually needed to support Windows, I am not sure, but yes, this is the excuse.

[wako@fosstodon.org]

@pinskia @thephd

You run autoreconf

(but you need the correct versions of autoconf and automake in your PATH, or running autoreconf will fail with an error)

[wako@fosstodon.org]

@pinskia @thephd running configure is not supposed to alter anything in the source tree, that initial expectation was wrong.

[wako@fosstodon.org]

@thephd no you don't need to downgrade anything, just install the necessary versions in some other location and add it earlier in your PATH when regenerating GCC configs. You don't need to touch the existing versions you have.

[wako@fosstodon.org]

@thephd if it changes so many things then you messed up (probably by running the wrong version and then not reverting the changes it made).

[wako@fosstodon.org]

@thephd no it would not help, please don't waste your time doing that. There are changes in newer versions which aren't necessarily compatible with how GCC does things, so updating to newer versions of the tools needs to be carefully audited to check every change to every generated file across the whole GCC tree (and maybe coordinated with gdb and binutils). It's a major undertaking, not just "hey I updated everything for you, here's the patch".

It's not just inertia.

[malwareminigun@infosec.exchange]

@uecker @diegovsky I have spent *more* time fighting with CMake but mostly as a function of it being used close to 100x as often.

[uecker@mastodon.social]

@malwareminigun @diegovsky We live in different worlds. From 10k packages I just built, for 5k the build logs mention a 'configure' script while 3k mention 'CMake'.

[malwareminigun@infosec.exchange]

@uecker OK "only" ~8% not the previous guess ~1%

[malwareminigun@infosec.exchange]

@uecker @diegovsky Ha! @meetingcpp survey question about this