3 ms·
Everyone's experience is different, but that's very different from my memory of autotools - a Turing-complete macro processor which generates several thousand l
by yongjik 6y ago
Everyone's experience is different, but that's very different from my memory of autotools - a Turing-complete macro processor which generates several thousand lines of pre-modern shell script with embedded C source codes. When anything goes wrong, it's pretty much impossible to match it to the original macro definition. Just so that one can hypothetically build the project in an ancient UNIX system which is so old that its shell doesn't even have functions.
- admax88q 6y agoIts difficult to match the origibal macro, but dead easy to match into the shell script. If youre just trying to get something to build as a user, its actually quite easy to read the configure script and see why its failing. The accompanied config.log is also quite detailed. Autotools are not the best, but i always prefer building autotools packages over cmake. Worst case i can modify the configure script directly.
- knorker 6y agoWhile I've not had that problem, I can see that it's nonobvious. But it's years between me looking at the actual compiled output. I look at assembly output more often, and most people never even do that. What I mean though is that ./configure outputs a config.log that says exactly what was done. Exactly what command line was run and exactly what the error was. I guess I'm confused why you're even looking at the compiled scripts. Would you not look at logfiles and stderr output before you start looking at assembly? CMake doesn't. The logs are completely useless, even when I get a CMake expert to come and agree, yes that's useless. With autotools you can see that it failed to build because it couldn't find library foo when building with "gcc blah blah blah", and you go "well yeah, you need -L/opt/foo/lib", so you just add that. (or pkg-config equiv). CMake, on the other hand, seems to force you to look at CMake "source code" (CMakeLists.txt), which is a horrible mess. I'm not saying autotools isn't (yay, m4 :-( ), but the point is you don't have to, because it actually logs what it does. So this is one of the many many reasons CMake sucks.
- jcelerier 6y ago> What I mean though is that ./configure outputs a config.log that says exactly what was done. Exactly what command line was run and exactly what the error was. ... so does CMake ? you get log of the errors in CMakeFiles/CMakeError.log, and you can trace what happens line by line in a very verbose way with cmake --trace (or cmake --trace-expand if you want variables to be expanded)
- yudlejoza 6y agoI just spent some time searching for m4 opinions on HN and it's more like a love-hate than hate-hate. It looks like if you dive head first into learning autotools, then m4 is going to look like nuisance. But if you allocate time to learn m4 for what it is, instead of just something you have to put up with as part of your autotools adventure, then you'll hate m4. m4 is the only (or one of a very few) well-known general-purpose language-agnostic macro processor I know of.
- knorker 6y agoI don't hate m4. Could be worse, could be better. I used to build websites using m4 back in the 90s. Back when static site generats were popular, before the latest slight resurgence. To misquote Mitch Hedberg: People either love it or hate it, or they think it's ok.
- yudlejoza 6y agocorrection: ... autotools adventure, then you might not hate m4.