Re: [cdesktopenv-devel] porting on Autotools initiative
On Sun, 3 Feb 2013 11:43:32 -0800 (PST), Oleksiy Ch wrote: > HI, > > I examined CDE it contains ancient Imakefiles. I think it must be ported on > Autotools as Motif did, but in a more wise way. I made some work in this way. > Currently I have lib dir ported on autotools completely. Actually the main > thing is configure.ac, it's 95% of code. It absorbed much from config/cf/*. > So with configure.ac the core part of porting is done. Current configure.ac > makes checks but don't abort on check fail. It's temporary. As someone having to deal with auto* on a daily basis in OpenBSD ports, please, please, please, please no. It is a major pain to work with and continues to waste hundreds of hours of developer time fighting with its quirks and stupidities. Imakefiles may not be the nicest or most modern build system around, but they get the job done and do so in a much more transparent manner than the monstrosity that is GNU auto*. So, please point out your reasoning *why* you think replacing Imakefiles is a necessity and why that replacement should be Autotools. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] porting on Autotools initiative
First of all I have to mention that taking all difficulty of maintaining autotools scripts we release users from having to handcraft Imake config and read manuals about how to build that application. Any user just want to configure && make install. And I like it too. Second configure scans your system for dependencies and gives you options. It will not start building if some dep lib is absent. So user would get a clear message what he needs to install instead of gcc error about some libxxx not found or unresolved symbols. Third Automake gives VPATH. This is absolutely must have. Automake gives many standard targets. Do you have something against libtool? In general it gives portability and simplicity for USER. It's not always simple for developer of course. But from my point of view auto* are not so weird. All you need is to know is M4 which looks elegant for me. If you will look into the crafted configure.ac you'll find a separate section for OpenBSD. In this section you can add custom tests and set config variables the same as in OpenBSD.cf. So don't worry man. If you'll have any questions please ask. And please if you insist not to use autotools give your arguments. What alternatives? I don't know other build tools that can be compared with auto*. And you know Motif was switched on autotools. Before it was on Imake. Actually it used almost the same config and rule files in config/cf. But they changed and it was a step forward. SO what's special about CDE? Alex From: Pascal Stumpf To: Oleksiy Ch Cc: "cdesktopenv-devel@lists.sourceforge.net" Sent: Sunday, February 3, 2013 10:08 PM Subject: Re: [cdesktopenv-devel] porting on Autotools initiative On Sun, 3 Feb 2013 11:43:32 -0800 (PST), Oleksiy Ch wrote: > HI, > > I examined CDE it contains ancient Imakefiles. I think it must be ported on > Autotools as Motif did, but in a more wise way. I made some work in this way. > Currently I have lib dir ported on autotools completely. Actually the main > thing is configure.ac, it's 95% of code. It absorbed much from config/cf/*. > So with configure.ac the core part of porting is done. Current configure.ac > makes checks but don't abort on check fail. It's temporary. As someone having to deal with auto* on a daily basis in OpenBSD ports, please, please, please, please no. It is a major pain to work with and continues to waste hundreds of hours of developer time fighting with its quirks and stupidities. Imakefiles may not be the nicest or most modern build system around, but they get the job done and do so in a much more transparent manner than the monstrosity that is GNU auto*. So, please point out your reasoning *why* you think replacing Imakefiles is a necessity and why that replacement should be Autotools.-- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
[cdesktopenv-devel] porting on Autotools initiative
Oleksiy Ch wrote: > HI, > > I examined CDE it contains ancient Imakefiles. I think it must be > ported on Autotools as Motif did, but in a more wise way. I made some WHY??! > work in this way. Currently I have lib dir ported on autotools > completely. Actually the main thing is configure.ac, it's 95% of code. > It absorbed much from config/cf/*. So with configure.ac the core part > of porting is done. Current configure.ac makes checks but don't abort > on check fail. It's temporary. > > > Patch in attachment. > > Comments? I agree with Pascal Stumpf's analysis. Autotools works, except when it doesn't. (sorry, rant coming...) Then you end up with things like -cross compiles FTBFS because it assumes that means sizeof(long) < sizeof(*void) (seen in Apache/APR), and then complains that the compiler is not standards conformant because sizeof long must equal or exceed sizeof *void. I don't know of any system that actually has this problem. -checking for malloc (!) gets stuck in an infinite loop (seen in Oleo) Make the obvious change (comment it out; I use obvious loosely), and it breaks the sylk file exporter. The real fix is to change the test, install autotools, and regenerate configure. Good luck figuring that out if you're a user, even one somewhat familiar with patching sources and fixing shell scripts. And of course, that requires GNU m4 1.4+ "because we need --prefix-builtins" even though GNU documents that -P is equivalent, and OpenBSD, NetBSD, and now FreeBSD have their own m4 versions support -P. Never mind that GNU m4 doesn't want to build on arbitrary systems because it uses freadahead from gnulib, which compiles on about 6 platforms; the alternative stub used to just abort(). -while we're on the subject of fixing things, I should mention the bug [1] filed by Debian's Samba maintainer: "automake: configure has mode 755" "...This is obviously completely inappropriate, as the code produced by automake is something that should never been seen by human eyes..." -send it an OS name that is not expressed the way GNU wants, and good luck having anything build. (config.sub and config.guess, I'm looking at you) -it claims to handle varying tools, but this frequently amounts to checking whether the GNU version is installed, and telling the user "You need to install the GNU version" If you're wondering why busybox sed --version outputs This is not GNU sed version 4.0 this is the reason (that matches the regexes used to check, so software builds) -In fact, it frequently ends up dragging in more dependencies on GNU tools (gmake, gm4, bash, and the list goes on) -it claims to test for features, but half the time the tests are along the lines of #ifdef __linux__ #ifdef __glibc__ .. #else /* assume libc5 */ #endif Which you might as well use imake for, and you'd get to building a lot sooner. And this is packagers' and porters' time, not just developers. In other words, AUTOCONF DOESN'T MAKE THINGS EASIER FOR USERS, unless you're talking about an extremely limited set of variations. And by the way, libtool is rather annoying too, because it doesn't properly handle certain things (for example, they exported an AIX misfeature so they broke static linking in most build systems...) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=140837 -- Isaac Dunham -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
