> Let the bikeshedding begin! :) Well, since you asked.... ;-)
Bill Joy (creator of "vi") once said, "Vi was created for a world that no longer exists." I think it's safe to say that the same is true of autotools. Most commercial UNIX flavors are dead, or may as well be, at least for E's purposes. Plus, FreeBSD offers Linux compatibility, and the most-used devices are mobile/embedded now anyway. The days for which autoconf and libtool were created are past us. I think Git proves that Kconfig can be both powerful and portable in the modern age, so I tend to recommend it nowadays. CMake is also a solid option. I tend to advise against the custom home-grown shell script since it's going to involve a lot of wheel re-invention, and Kconfig/CMake will almost certainly out-perform it...but it will still beat auto*/libtool. Just keep in mind that VTorri has said he will vamoose if the project abandons autotools, so if he still feels that way, that should factor into the decision.... Michael On Sun, Jan 15, 2017 at 7:30 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > I'm going to bring this up as it's highly controversial... and not everyone is > going to be happy, but doing NOTHING is worse. > > I spent a weekend doing LOTS of builds on my Raspberry Pi 3... and I have come > to realize some things: > > 1. Libtool is shit. Seriously. It provides no value for us. If anything is > provides vastly negative value. about 50% of all CPU time during make is spent > on executing a ~12k line libtool shell script. On a fast enough machine you > don't notice easily as the script runs then sleeps then the compiler kicks in > then it exists. it's hard to notice. on a pi I literally could watch the > libtool shell script think and burn CPU... for about 50% of the time. > > 2. Just running make chews cPU for multiple seconds (like 30 or so) as it has > to parse 55k +of Makefile(s) and figure them out. not I/O time statting stuff. > real CPU processing time. Before it even does anything useful. > 3. Re-running autogen.sh takes somewhere about the same time as does building > the rest of the software. > 4. Whenever we do make install these days libtool is friggin' re-linking > almost > everything. it's horrendous. A make install that should take < 5 seconds on a > fast intel box takes a minute. on a pi its even worse. > > A quick back-of-a-napkin math tells me we'd cut our full build times down > maybe > to 1/4 of what they are now by going with a raw hand-made makefile. For my > build set (efl + e + terminology + rage) that'd go from 2hrs to 30mins. It'd > drastically improve our productivity when developing. When hunting a bug and > "trying things" we have to wait for all that relinking mojo. It's horrible. > change anything in eina and it causes eo and eolian to rebuild which causes > regeneration of eolian output which causes even more rebuilds... When you're > fast cycling to find a bug this is the last thing you want. Technically it's > correct as they do depend on each-other but this is something we can deal with > on our own and test in the end with a full rebuild. When a full rebuild is 1/4 > the time it's far less painful. > > I think we really need to reconsider our build system. It's a drag on > productivity. It's been pissing me off now for a long time long before I got a > Pi. It's just an order of magnitude worse on a Pi. > > So here is our reality: > > 1. We don't need autotools esoteric OS support. We are a complex enough > library > set that a new OS requires us to port and support it. So we basically support > the following OS's: > > * Linux > * FreeBSD > * OpenBSD > * NetBSD > * Darwin/OSX > * Windows > * Solaris/Open Solaris/Open Indiana > > The Unixen outside the above list > > That's our reality. Anything else does require a specific port and work and so > could happily mean someone has to do build system work. They have to with > autotools anyway. So we don't need support other than the above, and any new > OS's need explicit support in code anyway so may as well add some > detection/customisations in the build system then too. > > 2. Very few people grok the .m4 stuff in our autotools and very few every > will. > Our m4 macros are there to make our configure.ac smaller and easier to > maintain > but combined our m4 + configure.ac blob id 24k lines of shell+m4 mix. > configure.ac alone is 6k lines. I am willing to bet we can do a cleaner > PURE /bin/sh configure is far far far less that 6k lines total for everything > we need. > > 3. The more time goes on, the more we fight with autofoo and do "weird stuff" > like code-generate during build (eolian) and the more we have to work around > autotools to get stuff done. > > 4. A lot of the stuff autotools does to be "technically correct" hurts us > rather than helps us. > > So given that.. what do we do? Options: > > * A shell script to replace configure + gen a Makefile.cfg & include from > our > Makefile(s) > * CMake > * KConfig > * Scons > * Waf > * Meson > * Ninja > * Jam > > Possibly more. I'm wary of adopting any "fancy build system" unless we truly > don't have to fight it and it brings a LOT of value with it. > > My personally takes of short,listing options are the top 3 above. A hand > rolled > simple makefile set with just enough shell to detect some things and gather > pkg-config stuff etc. followed by the kernel's KConfig setup and CMake. > > I know that with a hand rolled system we can about relinking, rebuilding all > of > efl if you touch a line in eina (by just not running makedeps... - you change > something in a shared header file that changes memory layout that needs a > rebuild then do a rebuild by hand - you should know to do this as a > developer). > > I do not know if cmake will be as nice to us. Kconfig i don't know. > > I propose that whatever we come up with should support at minimum the > following > build system "features": > > * configure --prefix=XXX > * configure --bindir=XXX > * configure --sysconfdir=XXX > * configure --libdir=XXX > * configure --includedir=XXX > * configure --datadir=XXX > * configure --localedir=XXX > * configure --mandir=XXX > * configure --docdir=XXX > * at least all the relevant configure features we added for efl > * make (from any dir/subdir) > * make install > * make uninstall > * make DESTDIR=xxx > * make dist > * make distcheck > * make check > * cross-compiling (--host=XXX --build=XXX) > * gettext support > > Let the bikeshedding begin! :) > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Michael Jennings (KainX) https://medium.com/@mej0/ <m...@eterm.org> Linux/HPC Systems Engineer, LANL.gov Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "The trouble with doing something right the first time is that nobody appreciates how difficult it was." -- Walt West ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
