On Tue, 17 Jan 2017 08:43:32 +0100 Adrien Nader <adr...@notk.org> said:
> Hi, > > I'm busy with other things but overall I find the content in the > discussion very disconcerting. > > Taking ffmpeg's so-called configure script as an example. > It. Is. A. Pile. Of. Crap. > How is *that* script any better than autoconf's chain? Has anyone here > actually read it? An autoconf 'configure' script is much more, and I > chose my words, friendly compared to that. > And did I mention the bugs? Which ones? Honestly, I don't remember > because I've never felt like using my memory to store others' stupid > shell mistakes. > > Has anyone in this thread actually called autoconf an issue? You don't > have to use automake and libtool simply because you use autoconf. i have. it was one of the very first points. autogen.sh (waiting on m4 madness, perl and friends) to generate a configure and running the configure takes about the same time compiling does on arm. it's at the very start. look at the sheer size of the configure.ac and how much we drop back to shell to handle nested and chained dependencies anyway. when you have to re-run autogen 10 times a day or more... having to wait matters. i re-ran it about 6 times on sunday... on my pi. i could have lunch while it processed. multiple lunches. on a ridiculously powerful x86 box which is far more efficient than arm on forking+execcing new processes it's 53 seconds to do an autogen.sh. the actual make for evl is 243 seconds. so 20% of all our build currently is that. remove libtool (my estimate is its 50% of our build) then autogen will be 33% of our build time. i end up having to run it many many many times. whatever thing in autotool - beats me what randomly decides (filex.la is the same file as filey.la) and not amount of rm'ing the files, make clean etc. fixes it. it needs a make clean distclean and thus a re-run of configure at a minimum of course... > Also note that gnu make is slower than other make implementations > because it does more things (including going through rules twice). it'll be slower if you have 50k lines of makefile to deal with for sure... :) > Obviously if you use automake which does everything to not depend on gnu > make but still depend on gnu make elsewhere, you're not gaining much on > any front. correct. so dump automake. we already depend on gnu make anyway so where's the value of automake? > As for libtool, a couple side-notes again. First it lets you run > executables without installing them first (somehow this is called > "uninstalled" rather than "not-yet-installed"). Second, it definitely this actually causes us pain. efl is relocatable runtime. we have all these special EFL_RUN_IN_TREE env var checking *IN CODE* to specially alter our location finding to work in tree because we don't do an install temporarily for execution. it's actually cleaner and simpler to do a tmp install in our tree somewhere. rpath for US causes work rather than do it the simple "tmp install" way. without the relinking madness an install should be sub 5 seconds. the relinking makes a 5 second make install become between 30-60 seconds... on a powerful machine. so givne this. dump libtool. we're down to JUSt autoconf. then take a read of all the configure.ac and m4 macros we have... it's a nightmare. it's far longer and more verbose than a lean purpose-made sh script would be to do just what we need. > does a lot things wrong but good luck faring better. faring better is pretty easy. as above. > Obviously, trying to contribute upstream seems impossible just like > getting involved with one of the several projects aiming at replacing > it. upstream autotools? > -- > Adrien Nader > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
