Results 1 ... 83 found in trilema for '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: this particular 'africa' tho is prion-contagious. the software derps decided that 'it's still a valid program' when imports GB of autoconfolade and 'appears to work'. the maffs people decided 'it's still a proof' when imports a GB of softwareliquishit and fits in 0 heads. the physics folx , that 'it's still physics' if used an irreproducible machine built by great inca. whereas per asciilifeform all of these people are pulling own co
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: http://btcbase.org/log/2019-07-19#1923538 << trinque if you have an alternative algo that avoids giga-genesis, i'd really like to hear about it asap, before we start genesising 100MB of kernelade complete with autoconfisms etc
asciilifeform: but e.g. trb , pretty heavy, 0 autoconf (in the proggy per se, that is; there is some in the deps, however)
asciilifeform: and yes legacy crapola that nobody got around to deautoconfing yet, do use, there's 9000 on my boxen. but what i touch with own hands , away it goes
asciilifeform: !#s from:asciilifeform autoconf
a111: 32 results for "from:asciilifeform autoconf", http://btcbase.org/log-search?q=from%3Aasciilifeform%20autoconf
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 wonders if ave1 got stuck tryin' to scrub out the autoconfolade
asciilifeform wonders how much of the 100 is autoconf garbage
asciilifeform: also gotta luvv how e.g. '3MB of autoconfolade' is somehow considered 'fleadom-related quality'
asciilifeform: mircea_popescu: they dun even like to mention that typical gnuturd is 80-90% autoconfolade by mass
asciilifeform: he will use 'libraries' and 'legacy' crapola and autoconf and etc.
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: hence the retardation of autoconfism
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: autoconf is a massive pile of shit.
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: now add to this, autoconf, 'libraries', the idjit os...
asciilifeform: well yes, recall where i bulldozered out the autoconfism in mpi
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: trinque: although, the end of the line in my eyes is : a fully deautoconfized set of packages.
asciilifeform currently marveling re how much ~time~ , as well as space, is wasted in autoconf
phf: obviously i'm not actually building it with 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
asciilifeform: kill autoconf. it has no place in this world.
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
asciilifeform: phf: lemme guess, it was by nuking autoconf
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: !#s autoconf
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: thank the nice folx who created autoconf.
a111: Logged on 2017-04-04 15:46 asciilifeform: hey i deautoconfed gpg's mpi lib 100%
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: it isn't clear to me that autoconf was EVER necessary
asciilifeform: hey i deautoconfed gpg's mpi lib 100%
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
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:17 mircea_popescu: and trying to implement a "better" autoconf, even "by hand", will not result in anything better
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
asciilifeform: configure.ac:10: error: Autoconf version 2.64 or higher is required
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.
fluffypony: autoconf is horrible
decimation: just like 99% of 'autoconf' use is cut n' paste
trinque: it also refers to the 169.254 autoconfig IPs and various other poetteringisms seen in avahi and bonjour
dhill: autoconf, different OSs, 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.