You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Ralf S. Engelschall" <rs...@engelschall.com> on 1999/06/11 09:19:21 UTC
Notes about APR's Autoconf stuff
A few Autoconf related notes to the guys working on APR. Do not treat this as
an offense, please. You're doing a great job working on this stuff. I just
want to share my opinion with you about things I've recently observed. I know
that I still do not work on APR myself and so it maybe is a pain for some of
you when I nevertheless express my opinion. But I think that some feedback
cannot be wrong and at least sharing my opinion could help you to even further
improve APR. I don't know whether the Autoconf stuff is important for you.
Perhaps it isn't. At least IMHO it is important for a beast like APR when it
wants to be a successful package and be what it's P in the name indicates.
1. The "if (test ..); then" constructs
> [...]
> +if (test "$SYS_SW" = "FreeBSD"); then
> [...]
Sorry when I ask (again?): What's the real intention behind these type of
if-constructs, i.e. why the parenthesis? Sure, inside Autoconf one usually
writes "test" instead of "[" ... "]", because the square brackets are the
delimiters of m4 in Autoconf. But why the parenthesis? They create a
subshell without need IMHO.
In other words:
if test "$SYS_SW" = "FreeBSD"; then
should be enough and will be faster. So, are the "if (test..); then"
constructs just by coincidence or accident or there a deeper intention I've
just still not understood? The only two situations where a subshell is
important is for 1. when you want to do a temporary "cd" and the old dir
cannot be assumed fixed or 2. when you want to test for the existance of a
program where you've to use constructs like var=`(program) 2>/dev/null`. But
I've to admit that although I wrote Autoconf stuff for many years I've never
seen reasons for "if (test...); then" constructs...
2. Autoconf and the feature/OS philosophy
I'm still wondering why you explicitly define the OS although you're using
Autoconf. Sure, sometimes one need an OS dependent kludge in the source (for
instance for my NPS library I've to recognize Linux and do a kludge because
Linux is the _only_ platform with a not working sigstack/sigaltstack, etc).
But usually the glory rule for Autoconf based project IMHO is: Replace all
direct OS kludges with feature-determined kludges.
The benefit? You're more portable, because the same kludge/situation is then
recognized for more than a single OS. An example: When you determine the OS
in Autoconf only, create -D<OS> and inside the source you've ``#if
defined(<OS1>) || defined(<OS2>)'' for one thing and you've ``#if
defined(<OS3>) || defined(<OS4>)'' for the alternative, etc. Then you're
program isn't _really_ portable. I personally call it then just
"semi-portable" because it was just "manually ported to a fixed set of N
operating systems". When you're on one of those N operating systems, you _can_
consider the program portable, of course. But it isn't "portable", because
when you're on the (N+1)th OS which isn't part of the already known set of
recognized OS then the program fails. And then you've to "port" it manually.
An example is MIT-pthreads. It's considered "portable" by lots of people,
but for me it's just "semi-portable" (although it's a great package, btw).
Because it has only a fixed set of known platforms to which it was ported.
There it works great. But for every additional platform horrible porting of
assembler code and other hacks start.
Really "portable" for me means this: Either you use only constructs which are
per definition portable (i.e. mainly only ANSI C features or functions
long known to the POSIX world) _OR_ you at least use a package like Autoconf
the _correct_ way. The correct way for me (proof me to be wrong) is this: You
test not for particular platforms for dispatching on it later in the source.
Instead you test for existing _features_ and dispatch later in the source
according to available features. Else you're program is just "semi-portable"
and for those Autoconf isn't required. Then you can avoid using it at all.
That's why I'm still confused by the APR stuff. Because I still do not
understand why it's both necessary to have subdirs for various platform
flavors (except perhaps for the reason that different build mechanisms have to
used: make vs. a GUI-tool, etc) and specialized #defines for the platforms.
Because when APR uses Autoconf (the correct way, of course) IMHO these things
can be completely avoided.
3. Autoconf and practice experiences
I do not know whether the guys working on APR have experiences or not with
Autoconf and source trees (I only know that Ken once said that he still starts
to learn Autoconf - that's ok). At least a quick look at the current
configure.in showed to me that not too much experience seem to exist (or at
least it's still not considered important). That's no problem, of course. When
you would have seen my first Autoconf scripts you would ROTFL on me ;)
So, don't treat this as an indoctrination, but I strongly recommend you to
look at existing Autoconf stuff of _clean_ packages. I learned most of the
gory Autoconf details by studying existing Autoconf stuff. Five years ago this
was a pain, I've to admit. There were only unclean Autoconf stuff. But today
lots of good and clean Autoconf examples exists. Look at these when you want
to improve your stuff. Don't look at the large packages which use Autoconf,
they confuse because of already too much kludges which were added over time.
Look at small libraries and small packages using Autoconf.
Although I'm now biased when I say this, but my personal recommendation is to
look at MM. For these particular reasons: 1. It has to check lots of platform
stuff, but I think it does it the correct way and the package is small enough
to not be confused by kludges; 2. it shows you how one can combine Autoconf
with libtool and shtool the manual non-Automake way (I also recommend APR to
use these tools, at least libtool); 3. it uses a nifty decision hierarchy
concept multiple times to find the best implementation approach which can be
very useful in a smimilar way for APR. Because it gives features an order
relation which is important when multiple features exists on a platform but
they cannot be treated equal in features/side-effects, etc.
There are similar packages like MM where you additionally also can find good
examples. The way to find them is to use FTPSearch and searching for the files
"aclocal.m4" on the net. Download them all(!) and concatenate them. Then when
you've a problem, _ALWAYS_ first grep inside this large example pool. For all
standard situations Autoconf's distributed macros are enough. And even for most
of the esoteric situations someone usually already has written a solution
which you can find this way.
-
Sorry when I cannot work on APR myself. But perhaps at least the above hints
help you a little bit to improve APR even further.
Greetings,
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com
Re: Notes about APR's Autoconf stuff
Posted by Ben Laurie <be...@algroup.co.uk>.
Rodent of Unusual Size wrote:
>
> Ben Laurie wrote:
> >
> > Not being an autoconf guru, I will refrain from comment on the rest, but
> > on this point I agree 110%. If you detect the OS with autoconf, then you
> > lose.
>
> I'm an autoconf neophyte (if that!), but I don't see how else
> you're supposed to be able to deal with OS-specific things like
> compiler flags.. Enlighten me?
You are supposed to test for whether they are needed, work, or have the
desired effect (as appropriate). I'll agree that this isn't always
possible, but for the vast majority of cases it is trivial.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Notes about APR's Autoconf stuff
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ben Laurie wrote:
>
> Not being an autoconf guru, I will refrain from comment on the rest, but
> on this point I agree 110%. If you detect the OS with autoconf, then you
> lose.
I'm an autoconf neophyte (if that!), but I don't see how else
you're supposed to be able to deal with OS-specific things like
compiler flags.. Enlighten me?
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: Notes about APR's Autoconf stuff
Posted by Ben Laurie <be...@algroup.co.uk>.
Ralf S. Engelschall wrote:
> 2. Autoconf and the feature/OS philosophy
>
> I'm still wondering why you explicitly define the OS although you're using
> Autoconf. Sure, sometimes one need an OS dependent kludge in the source (for
> instance for my NPS library I've to recognize Linux and do a kludge because
> Linux is the _only_ platform with a not working sigstack/sigaltstack, etc).
> But usually the glory rule for Autoconf based project IMHO is: Replace all
> direct OS kludges with feature-determined kludges.
Not being an autoconf guru, I will refrain from comment on the rest, but
on this point I agree 110%. If you detect the OS with autoconf, then you
lose.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Notes about APR's Autoconf stuff
Posted by Greg Stein <gs...@lyra.org>.
Ralf S. Engelschall wrote:
>...
> That's why I'm still confused by the APR stuff. Because I still do not
> understand why it's both necessary to have subdirs for various platform
> flavors (except perhaps for the reason that different build mechanisms have to
> used: make vs. a GUI-tool, etc) and specialized #defines for the platforms.
> Because when APR uses Autoconf (the correct way, of course) IMHO these things
> can be completely avoided.
The subdir thing has been in the back of my mind, too... It seems like
it will create a serious maintenance headache. If subdir A is a copy of
subdir B, with some tweaks to get it to work for platform A... then what
happens when you find a bug in B? Do you now have to go and replicate
that fix through all the other subdirs?
I do understand the need to just get everything written, but I would
hope there is a plan afoot to pull it all back together and base it on
feature tests rather than cut/paste copies of code.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Notes about APR's Autoconf stuff
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
I am going to try to answer all of the APR autoconf concerns at once. :)
Ralf, thank you for your suggestions. Autoconf is a new tool for me. I
am planning on taking some time to really learn how to use it. I have
read your suggestions, and at some point, I will work on implementing
them. As far as why it works the way it does right now, that is because,
I believe, that is how ./configure does it now. At the time, it seeed
like as good a way to start as any.
As for location of the apr stuff, the directories may or may not merge in
the future. When I designed the directory structure, te goal was to
divide the code into as general groups as possible. That is why ALL of
the Unix code is in one spot. the Windows code doesn't fit well into the
Unix code, and it would get ugly quickly if we tried to make it fit.
Although I haven't looked at the OS/2 code in great detail, I believe it
has the same problem. I can easily see the BeOS code being merged into
Unix in the not too distant future. The code just isn't that different.
While this may mean that some times bugs will need to be fixed in multiple
places, but it shouldn't happen often, because the code just isn't that
similar.
Ryan
On Fri, 11 Jun 1999, Ralf S. Engelschall wrote:
>
> A few Autoconf related notes to the guys working on APR. Do not treat this as
> an offense, please. You're doing a great job working on this stuff. I just
> want to share my opinion with you about things I've recently observed. I know
> that I still do not work on APR myself and so it maybe is a pain for some of
> you when I nevertheless express my opinion. But I think that some feedback
> cannot be wrong and at least sharing my opinion could help you to even further
> improve APR. I don't know whether the Autoconf stuff is important for you.
> Perhaps it isn't. At least IMHO it is important for a beast like APR when it
> wants to be a successful package and be what it's P in the name indicates.
>
> 1. The "if (test ..); then" constructs
>
> > [...]
> > +if (test "$SYS_SW" = "FreeBSD"); then
> > [...]
>
> Sorry when I ask (again?): What's the real intention behind these type of
> if-constructs, i.e. why the parenthesis? Sure, inside Autoconf one usually
> writes "test" instead of "[" ... "]", because the square brackets are the
> delimiters of m4 in Autoconf. But why the parenthesis? They create a
> subshell without need IMHO.
>
> In other words:
>
> if test "$SYS_SW" = "FreeBSD"; then
>
> should be enough and will be faster. So, are the "if (test..); then"
> constructs just by coincidence or accident or there a deeper intention I've
> just still not understood? The only two situations where a subshell is
> important is for 1. when you want to do a temporary "cd" and the old dir
> cannot be assumed fixed or 2. when you want to test for the existance of a
> program where you've to use constructs like var=`(program) 2>/dev/null`. But
> I've to admit that although I wrote Autoconf stuff for many years I've never
> seen reasons for "if (test...); then" constructs...
>
> 2. Autoconf and the feature/OS philosophy
>
> I'm still wondering why you explicitly define the OS although you're using
> Autoconf. Sure, sometimes one need an OS dependent kludge in the source (for
> instance for my NPS library I've to recognize Linux and do a kludge because
> Linux is the _only_ platform with a not working sigstack/sigaltstack, etc).
> But usually the glory rule for Autoconf based project IMHO is: Replace all
> direct OS kludges with feature-determined kludges.
>
> The benefit? You're more portable, because the same kludge/situation is then
> recognized for more than a single OS. An example: When you determine the OS
> in Autoconf only, create -D<OS> and inside the source you've ``#if
> defined(<OS1>) || defined(<OS2>)'' for one thing and you've ``#if
> defined(<OS3>) || defined(<OS4>)'' for the alternative, etc. Then you're
> program isn't _really_ portable. I personally call it then just
> "semi-portable" because it was just "manually ported to a fixed set of N
> operating systems". When you're on one of those N operating systems, you _can_
> consider the program portable, of course. But it isn't "portable", because
> when you're on the (N+1)th OS which isn't part of the already known set of
> recognized OS then the program fails. And then you've to "port" it manually.
>
> An example is MIT-pthreads. It's considered "portable" by lots of people,
> but for me it's just "semi-portable" (although it's a great package, btw).
> Because it has only a fixed set of known platforms to which it was ported.
> There it works great. But for every additional platform horrible porting of
> assembler code and other hacks start.
>
> Really "portable" for me means this: Either you use only constructs which are
> per definition portable (i.e. mainly only ANSI C features or functions
> long known to the POSIX world) _OR_ you at least use a package like Autoconf
> the _correct_ way. The correct way for me (proof me to be wrong) is this: You
> test not for particular platforms for dispatching on it later in the source.
> Instead you test for existing _features_ and dispatch later in the source
> according to available features. Else you're program is just "semi-portable"
> and for those Autoconf isn't required. Then you can avoid using it at all.
>
> That's why I'm still confused by the APR stuff. Because I still do not
> understand why it's both necessary to have subdirs for various platform
> flavors (except perhaps for the reason that different build mechanisms have to
> used: make vs. a GUI-tool, etc) and specialized #defines for the platforms.
> Because when APR uses Autoconf (the correct way, of course) IMHO these things
> can be completely avoided.
>
> 3. Autoconf and practice experiences
>
> I do not know whether the guys working on APR have experiences or not with
> Autoconf and source trees (I only know that Ken once said that he still starts
> to learn Autoconf - that's ok). At least a quick look at the current
> configure.in showed to me that not too much experience seem to exist (or at
> least it's still not considered important). That's no problem, of course. When
> you would have seen my first Autoconf scripts you would ROTFL on me ;)
>
> So, don't treat this as an indoctrination, but I strongly recommend you to
> look at existing Autoconf stuff of _clean_ packages. I learned most of the
> gory Autoconf details by studying existing Autoconf stuff. Five years ago this
> was a pain, I've to admit. There were only unclean Autoconf stuff. But today
> lots of good and clean Autoconf examples exists. Look at these when you want
> to improve your stuff. Don't look at the large packages which use Autoconf,
> they confuse because of already too much kludges which were added over time.
> Look at small libraries and small packages using Autoconf.
>
> Although I'm now biased when I say this, but my personal recommendation is to
> look at MM. For these particular reasons: 1. It has to check lots of platform
> stuff, but I think it does it the correct way and the package is small enough
> to not be confused by kludges; 2. it shows you how one can combine Autoconf
> with libtool and shtool the manual non-Automake way (I also recommend APR to
> use these tools, at least libtool); 3. it uses a nifty decision hierarchy
> concept multiple times to find the best implementation approach which can be
> very useful in a smimilar way for APR. Because it gives features an order
> relation which is important when multiple features exists on a platform but
> they cannot be treated equal in features/side-effects, etc.
>
> There are similar packages like MM where you additionally also can find good
> examples. The way to find them is to use FTPSearch and searching for the files
> "aclocal.m4" on the net. Download them all(!) and concatenate them. Then when
> you've a problem, _ALWAYS_ first grep inside this large example pool. For all
> standard situations Autoconf's distributed macros are enough. And even for most
> of the esoteric situations someone usually already has written a solution
> which you can find this way.
>
> -
>
> Sorry when I cannot work on APR myself. But perhaps at least the above hints
> help you a little bit to improve APR even further.
>
> Greetings,
> Ralf S. Engelschall
> rse@engelschall.com
> www.engelschall.com
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.