tmsr - Search: autoconf

trinque: I don't think you expect to actually be yourselves patching acpica autoconf automake bash bc bison bzip2 cl-hyperspec clisp dash db flex gales-util gcc64 git gnupg less libevent libressl libusb links m4 man-pages man-pages-posix mandoc ncurses nginx ocaml openssh patch pciutils perl php56 py-setuptools python python-docs qmail readline redis sbcl sqlite sqlite-doc tmux ucspi-tcp vim xz zlib

jfw: there is ugly complexity in gcc to support this multitude of systems, such as 'fixincludes' and of course autoconf

mp_en_viaje: i don't imagine we'll be able to ditch autoconf in principle, until many years later, many years AFTER tmsr-os is a thing

diana_coman: mp_en_viaje: re moving cs I had a look in more detail at the situation there: there are 3k lines of autoconf script to start with; this looks for all sorts and takes care of various cases including differences (re where is what) between linux distros

asciilifeform: ( typical gnutardism, historically, is coupla 100kB of actual sores, and several MB of autoconf ! )

asciilifeform: ( aaand, cannot resist to pose the q, what % of this mass is autoconf liquishit ? )

asciilifeform: but e.g. trb , pretty heavy, 0 autoconf (in the proggy per se, that is; there is some in the deps, however)

asciilifeform: re autoconf, asciilifeform considers autoconfism an evil, and none of his productions ever used it or ever will

mircea_popescu: traditionally most everyone uses autoconf/automake for build automation fwis. well, at least eulora does.

a111: Logged on 2017-07-08 03:49 asciilifeform: i just counted gpg 1.4.10 : 156,436 loc -- and that ain't counting the autoconf liquishit, or the libs it pulls in

asciilifeform: http://btcbase.org/log/2019-03-30#1906193 << interestingly, at 139.2 kloc , still 1 of the heaviest proggies in civilized use; vs, e.g., trb ( http://btcbase.org/log/2018-11-29#1876053 ) ; but lighter than koch gpg ( if minus autoconf, http://btcbase.org/log/2017-07-08#1680705 ) or linux kern. ☝︎☝︎☝︎

asciilifeform: point was re rms. trouble with the man is, i dun think he is stupid, in the usual sense, he appears to quite deliberately think that cultivated fungus on ~coad~ is a valid defense against 'microshit will steal'. hence gcc, autoconf, other marvels.

asciilifeform: granted ave1's gnat still has 'miles to go' in some aspects, gotta be de-autoconf'd ( asciilifeform aint ever signing ANYTHING with autoconfolade in it ) and genesis'd. but it worx a++, is portable (to arm, currently) and is frozen, which is good bit moar than can be said for adacore's thing

a111: Logged on 2017-07-08 03:49 asciilifeform: i just counted gpg 1.4.10 : 156,436 loc -- and that ain't counting the autoconf liquishit, or the libs it pulls in

asciilifeform: ( i have said before, would like to see the autoconf atrocity properly disappear into an unmarked grave )

asciilifeform: trinque: gprbuild is replacement for gnumake/autoconf liquishit, not so much for portagetron per se.

asciilifeform: i suspect that 'only tip of iceberg' re autoconf breakage has been seen so far.

asciilifeform: 5-6 hours later ( the parallelization thing dun seem to work, and good chunk of time is spent in autoconf, which never parallelizes ) you get x86-64 and arm64 gnats

asciilifeform: was massive, cancerous ball of autoconf and ???? even decade ago, aha.

asciilifeform: incidentally bellard's tcc is not in any simple way trimmable, no autoconf garbage or the like, in there.

a111: Logged on 2017-12-20 03:17 asciilifeform: trinque: forget autoconf flags. i want to disable the generation or loading of dyn libs, period.

asciilifeform: trinque: forget autoconf flags. i want to disable the generation or loading of dyn libs, period. ☟︎

asciilifeform currently marveling re how much ~time~ , as well as space, is wasted in autoconf

asciilifeform: i suspect that if you ditch autoconf, and snip out ALL #ifdef crapola (esp. and inclusive of uniturdism and 'localism' ) you will end up with a sysv-sized util

phf: well, autoconf is not just scripts. it's also compatibility shims, which is a bit tricky in case of a differ, since, unlike mpi, it has a lot of file system interaction code, that might or might not be portable. anyway, we'll see

phf: it's not even the entirety of autoconf, just things that are left un-included after fixing all the "missing file" errors from diff.c

a111: Logged on 2017-04-04 15:43 asciilifeform: the far bigger boojum is that ~95% of the tarballs include megabytes of autoconf liquishit.

asciilifeform: 'Needless to say, this is more than most programmers would ever want to put up with, even if they had the skill, so the input files for autoconf happen by copy and paste, often hiding behind increasingly bloated standard macros covering "standard tests" such as those mentioned earlier, which look for compatibility problems not seen in the past 20 years'

a111: Logged on 2017-07-08 03:49 asciilifeform: i just counted gpg 1.4.10 : 156,436 loc -- and that ain't counting the autoconf liquishit, or the libs it pulls in

asciilifeform: i just counted gpg 1.4.10 : 156,436 loc -- and that ain't counting the autoconf liquishit, or the libs it pulls in ☟︎☟︎☟︎

asciilifeform: it was an instance of exactly same thing. ANY attempt to paper over 'i have nfi what the user has, let's support 10,000,001 possible braindamages' ends up looking like autoconf.

asciilifeform: trinque: except that it doesn't enable anybody -- if autoconf fails to find the headers, you are just as fucked as ever, gotta sit and puzzle out what environment flags to give it so that it has a sporting chance

a111: Logged on 2016-08-22 14:07 asciilifeform: http://btcbase.org/log/2016-08-22#1526632 << this is entirely correct. the 'problem' which autoconf pretends (yes, pretends) to 'solve', is EVIL

asciilifeform: the far bigger boojum is that ~95% of the tarballs include megabytes of autoconf liquishit. ☟︎

phf: diana_coman: i think i didn't say enough on the subject. the core of what i did in order to get it to build on mac os x is fix autoconf scripts, if i revisit mac os x build in a couple of weeks, i'll try and provide a portable patch

a111: Logged on 2016-08-22 03:17 mircea_popescu: and trying to implement a "better" autoconf, even "by hand", will not result in anything better

asciilifeform: http://btcbase.org/log/2016-08-22#1526632 << this is entirely correct. the 'problem' which autoconf pretends (yes, pretends) to 'solve', is EVIL ☝︎☟︎

a111: Logged on 2016-08-22 03:02 mircea_popescu: basically, seems to me most, or at least a good chunk of autoconf problems as described by alf come from the fact that it tries to parse, rather than compile. in the abstract sense of these terms.

BingoBoingo: <phf> i think crystal whatever is particularly nasty take on autoconf, probably one of the best examples in support of asciilifeform's rants. << Nah, "Monero" is far worse because of what it supposes to be.

phf: do you know if my changes were integrated into the release? because last time i checked the build wasn't doing autoconf, but simply using patches generated scripts.

phf: only worse autoconf build i've seen was clisp, but in the later case it was written by one of autoconf authors, so while it was elaborate it was at the very least sane

phf: i think crystal whatever is particularly nasty take on autoconf, probably one of the best examples in support of asciilifeform's rants.

mircea_popescu: and trying to implement a "better" autoconf, even "by hand", will not result in anything better ☟︎

phf: but autoconf being at the subtrate level is testament to "unix won", its purpose to give you details about "what's unix" given the tools that are available at the most abstract level of unixness

mircea_popescu: but it is evident the blame isn't autoconf's per se.

mircea_popescu: basically, seems to me most, or at least a good chunk of autoconf problems as described by alf come from the fact that it tries to parse, rather than compile. in the abstract sense of these terms. ☟︎

mircea_popescu: let's work with an abstract example. suppose there's project X, which can for the purpose of configure be reduced to a list of n lines, whereby each line produces a dependency from the list of D1- D5 by the criterion that line# mod 5. so a sane autoconf will read the whole list, produce a list reading "d1, d2, d3, d4, d5" and then proceed to check these. once. five fucking checks, five lines of checking.

phf: mircea_popescu: well, there's the primary file, which is your *.ac, which using autoconf generates your ./configure Makefile.in etc. ~those~ can be shipped with project and will work out of the box

mircea_popescu: no, because no "autoconf" nor "make" bs

phf: jurov: mac os x build of eulora uses clang, there might be some insight in the patches. specifically i go the whole way of patching/making sure it works autoconf for crystal space, which might be necessary to move forward with any sort of linking issues, etc.

decimation: re: autoconf << horrible. whoever thought it was a good idea to write 'magic autoconfigure' in 'm4' ought to be negrated

asciilifeform: autoconf, what a sad joke. so often dwarfs the proggy it's distributed with!

asciilifeform: as opposed to monstrous build process for recent codebases << gnu autoconf is the culprit 99%

asciilifeform: this is not high science, it was the original intent of the lowly gnu autoconf, even.