Taking all the pitfalls of autotools it should be stated that it covers all
imake capabilities plus adds a bunch of new features. Imake is just static. And
this is a big advantage/disadvantage. You look only at one side - advantage.
It's static so it's great for maintainer that doesn't like things that change.
For this case a minimal portable configure.ac can be crafted that reads *.cf
and *.rules and you get all Imake capabilities plus shell to do tests and all
autotools capabilities. Let's make preset defines for different OSes that do
not change if we select that OS in configure option: configure
--preset-config=OS [openbsd freebsd linux sun ibm hp ...]
>> -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)
Add option with strictly defined OS names derived from file names
config/cf/*.cf.
You may want try to autodetect OS first. There are systems not detectable by
config.guess, like USL. But these are too ancient systems. Who uses them now?
All systems past 199x are detectable and many that existed before. In any case
if you get unknown $host you may run your own tests on portable shell or guess
OS name or class from standard preprocessor defines that config.guess missed.
Because you have shell in your hands. As a last resort you can just ask user by
giving him a list of supported systems to select from (config/cf/*.cf).
Of course config.guess can't detect os major and minor versions. So write your
tests. If tests fail ask user (now it's like Imake).
>> -it claims to handle varying tools, but this frequently amounts to
checking whether the GNU version is installed, and telling the user
don't use that macros. Write your own macro that checks Sed in a write way. Or
skip checking if selected option to use preset defines for some OS. So we
return to Imake way.
>> -it claims to test for features, but half the time the tests are along the
>> lines of
don't used that macros. That's all. Write your own macro, more correct. Or skip
testing and use preconfigured defines by selecting OS in configure option.
>> -while we're on the subject of fixing things, I should mention the bug [1]
>> filed by Debian's Samba maintainer:
agree
>> -In fact, it frequently ends up dragging in more dependencies on GNU tools
>> (gmake, gm4, bash, and the list goes on)
don't use that macro
>> And of course, that requires GNU m4 1.4+ "because we need
just don't use that macro, if I understand you right
>> Autotools works, except when it doesn't.
Let's make backward compatibility by putting all preset defines in configure.ac
All your headache can be resolved by using preset config option.
Think about user. Does he want to read a manual to find out how to switch off
that module in compile time that requires some dep that don't want to install.
Why do you pass over all features that autotools give?
Alex
________________________________
From: Isaac Dunham <ibid...@lavabit.com>
To: cdesktopenv-devel@lists.sourceforge.net
Sent: Monday, February 4, 2013 8:39 AM
Subject: [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 <ibid...@lavabit.com>
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
