@pinskia Idiot noob question about the Makefile.am in libstdc++-v3 --
-
@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."
@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.
-
-
-
configure.ac:36: error: Please use exactly Autoconf 2.69 instead of 2.72.
config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:36: the top level
autom4te: error: /usr/bin/m4 failed with exit status: 1
automake: error: autoconf failed with exit status: 1Hm.
Well. I guess I need to downgrade my stuff.
@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.
-
Finally getting to run the script changes so many things that I actually think it's better for me to just surgically change what's needed and then say I "regenerated" it. The new run of
automakechanges like 18 different files that I did not touch at all.@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).
-
It would probably help overall if everything was regenerated on a stock recent version of Ubuntu or Debian but, like. I can't have that being part of this pull request.
@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 @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.
@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 @diegovsky I have spent *more* time fighting with CMake but mostly as a function of it being used close to 100x as often.
@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 @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'.
@uecker OK "only" ~8% not the previous guess ~1%
-
@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'.
@uecker @diegovsky Ha! @meetingcpp survey question about this
-
R relay@relay.infosec.exchange shared this topic
