You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "Roy T. Fielding" <fi...@ebuilt.com> on 2001/02/13 08:30:47 UTC
Re: build blues
Just a heads-up. I am still working on simplifying the build scripts.
More changes are required for httpd than anything else, though I'd also
like to streamline, name-protect, and make consistent the apr stuff.
This is taking a lot longer than expected because the current setup
has coupling among 50 or so different files and I have to backtrace
each of the macros just to figure out what is safe to change.
This is what I have already done in my local copy:
* removed the need for httpd build.mk, build2.mk, bsd_makefile, ...
using the same technique as apr (i.e., rules.mk.in)
* created apr/build (to eventually replace apr/helpers) and
moved all the hard checks into apr.
* standardized on ./buildconf.sh and ./build/
* merged apr-conf.m4 and apr_common.m4 into build/acinclude.m4
and name-protected all of the macro names
-- have not yet name-protected the variables within the macros
* removed some unused macros
* moved the REENTRANCY_FLAGS settings into hints.m4
-- this is actually a bug in the current process
-- we need to define these flags even if apr is --disable-pthreads,
since they affect how errno is interpreted and the current
library relies on apr being consistent with apr's clients.
httpd always defines these flags for the same reason.
* added MKEXPORT, MKDEP, and SCANDOC substitutions to rules.mk.in
so that the Makefile.in files never need to know the paths.
* libtoolize --automake --copy --force
[the only way we ever want to call libtoolize]
All of the above is done for apr and it is building fine. What I still
need to do is
* make each "top-most" buildconf.sh set up the subdirectory configures
directly with autoheader and autoconf, rather than running each of
their buildconf.sh scripts. This will remove most of the redundant
libtool and configure checks, force the whole tree to be built with a
consistent set of flags, and allow each independent tree's buildconf.sh
to be specialized for standalone builds of that tree.
* make apr-util build upon what was generated by apr configure
-- easy, since Greg mostly set it up like this already
* make httpd build upon what was generated by apr-util + apr
* modify all of the Makefile.in files to use the new @VARS@
And, after the rest is done and committed, maybe
* make it possible to build static without libtool
* fix dependencies so that they are created by configure
....Roy
Re: build blues
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 13, 2001 at 02:01:33PM -0800, Roy T. Fielding wrote:
> On Tue, Feb 13, 2001 at 12:58:04AM -0800, Greg Stein wrote:
> > Is it possible to get a partial checkin? That'll let us review pieces as
> > they go (easier to do a small bit, than a huge one), and you won't have to
> > worry about tracking other changes to the build system.
>
> The APR changes include changing the directory name from helpers
> to build and the filename from buildconf to buildconf.sh, which pretty
> much eliminates the commit diff. The nice thing is that it will
> be easy to resurrect the old buildconf if needed.
>
> I could make the changes one-by-one, but it would effectively double
> my work because none of the interim changes would survive.
Understood. Not trying to impose work, but just hoping that your output is
reviewable so that we can see/learn/understand the changes you're making.
> > >...
> > > * make each "top-most" buildconf.sh set up the subdirectory configures
> > > directly with autoheader and autoconf, rather than running each of
> > > their buildconf.sh scripts. This will remove most of the redundant
> > > libtool and configure checks, force the whole tree to be built with a
> > > consistent set of flags, and allow each independent tree's buildconf.sh
> > > to be specialized for standalone builds of that tree.
> >
> > Not sure about this one. Are you talking about APR building a libtool, and
> > having the other pieces just use APR's copy?
>
> Whichever buildconf is called first would create the libtool and
> define BUILD_BASE for use by the others.
APR's buildconf will always be the first, no?
I mean, we couldn't really have APR and APRUTIL using Apache's libtool,
could we?
> > >...
> > > * modify all of the Makefile.in files to use the new @VARS@
> >
> > I'm presuming that your @VARS@ is intended to replace config_vars.mk. Why
> > put it into each Makefile.in? Couldn't the @VARS@ just go into rules.mk.in?
>
> Yes, they go in rules.mk.in, but the $(VARS) and @INCLUDE_RULES@ need to be
> added to the individual Makefile.in files.
I'll have to see this when you're done (don't feel obligated to spend more
time explaining) cuz I still don't understand. If @INCLUDE_RULES@ is
including rules.mk, then each Makefile wouldn't need to have its own @VARS@
since they'd just pick it up from rules.mk.
btw, if you happen to be touching every APR Makefile.in, the INCLUDES stuff
can be collapsed into rules.mk.in. I didn't do it last time cuz it was a
bundle of work already. If you don't mind more pain, then that task is still
waiting :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: build blues
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 13, 2001 at 02:01:33PM -0800, Roy T. Fielding wrote:
> On Tue, Feb 13, 2001 at 12:58:04AM -0800, Greg Stein wrote:
> > Is it possible to get a partial checkin? That'll let us review pieces as
> > they go (easier to do a small bit, than a huge one), and you won't have to
> > worry about tracking other changes to the build system.
>
> The APR changes include changing the directory name from helpers
> to build and the filename from buildconf to buildconf.sh, which pretty
> much eliminates the commit diff. The nice thing is that it will
> be easy to resurrect the old buildconf if needed.
>
> I could make the changes one-by-one, but it would effectively double
> my work because none of the interim changes would survive.
Understood. Not trying to impose work, but just hoping that your output is
reviewable so that we can see/learn/understand the changes you're making.
> > >...
> > > * make each "top-most" buildconf.sh set up the subdirectory configures
> > > directly with autoheader and autoconf, rather than running each of
> > > their buildconf.sh scripts. This will remove most of the redundant
> > > libtool and configure checks, force the whole tree to be built with a
> > > consistent set of flags, and allow each independent tree's buildconf.sh
> > > to be specialized for standalone builds of that tree.
> >
> > Not sure about this one. Are you talking about APR building a libtool, and
> > having the other pieces just use APR's copy?
>
> Whichever buildconf is called first would create the libtool and
> define BUILD_BASE for use by the others.
APR's buildconf will always be the first, no?
I mean, we couldn't really have APR and APRUTIL using Apache's libtool,
could we?
> > >...
> > > * modify all of the Makefile.in files to use the new @VARS@
> >
> > I'm presuming that your @VARS@ is intended to replace config_vars.mk. Why
> > put it into each Makefile.in? Couldn't the @VARS@ just go into rules.mk.in?
>
> Yes, they go in rules.mk.in, but the $(VARS) and @INCLUDE_RULES@ need to be
> added to the individual Makefile.in files.
I'll have to see this when you're done (don't feel obligated to spend more
time explaining) cuz I still don't understand. If @INCLUDE_RULES@ is
including rules.mk, then each Makefile wouldn't need to have its own @VARS@
since they'd just pick it up from rules.mk.
btw, if you happen to be touching every APR Makefile.in, the INCLUDES stuff
can be collapsed into rules.mk.in. I didn't do it last time cuz it was a
bundle of work already. If you don't mind more pain, then that task is still
waiting :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Tue, Feb 13, 2001 at 12:58:04AM -0800, Greg Stein wrote:
> Is it possible to get a partial checkin? That'll let us review pieces as
> they go (easier to do a small bit, than a huge one), and you won't have to
> worry about tracking other changes to the build system.
The APR changes include changing the directory name from helpers
to build and the filename from buildconf to buildconf.sh, which pretty
much eliminates the commit diff. The nice thing is that it will
be easy to resurrect the old buildconf if needed.
I could make the changes one-by-one, but it would effectively double
my work because none of the interim changes would survive.
> >...
> > * make each "top-most" buildconf.sh set up the subdirectory configures
> > directly with autoheader and autoconf, rather than running each of
> > their buildconf.sh scripts. This will remove most of the redundant
> > libtool and configure checks, force the whole tree to be built with a
> > consistent set of flags, and allow each independent tree's buildconf.sh
> > to be specialized for standalone builds of that tree.
>
> Not sure about this one. Are you talking about APR building a libtool, and
> having the other pieces just use APR's copy?
Whichever buildconf is called first would create the libtool and
define BUILD_BASE for use by the others.
> >...
> > * modify all of the Makefile.in files to use the new @VARS@
>
> I'm presuming that your @VARS@ is intended to replace config_vars.mk. Why
> put it into each Makefile.in? Couldn't the @VARS@ just go into rules.mk.in?
Yes, they go in rules.mk.in, but the $(VARS) and @INCLUDE_RULES@ need to be
added to the individual Makefile.in files.
....Roy
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Tue, Feb 13, 2001 at 12:58:04AM -0800, Greg Stein wrote:
> Is it possible to get a partial checkin? That'll let us review pieces as
> they go (easier to do a small bit, than a huge one), and you won't have to
> worry about tracking other changes to the build system.
The APR changes include changing the directory name from helpers
to build and the filename from buildconf to buildconf.sh, which pretty
much eliminates the commit diff. The nice thing is that it will
be easy to resurrect the old buildconf if needed.
I could make the changes one-by-one, but it would effectively double
my work because none of the interim changes would survive.
> >...
> > * make each "top-most" buildconf.sh set up the subdirectory configures
> > directly with autoheader and autoconf, rather than running each of
> > their buildconf.sh scripts. This will remove most of the redundant
> > libtool and configure checks, force the whole tree to be built with a
> > consistent set of flags, and allow each independent tree's buildconf.sh
> > to be specialized for standalone builds of that tree.
>
> Not sure about this one. Are you talking about APR building a libtool, and
> having the other pieces just use APR's copy?
Whichever buildconf is called first would create the libtool and
define BUILD_BASE for use by the others.
> >...
> > * modify all of the Makefile.in files to use the new @VARS@
>
> I'm presuming that your @VARS@ is intended to replace config_vars.mk. Why
> put it into each Makefile.in? Couldn't the @VARS@ just go into rules.mk.in?
Yes, they go in rules.mk.in, but the $(VARS) and @INCLUDE_RULES@ need to be
added to the individual Makefile.in files.
....Roy
Re: build blues
Posted by Greg Stein <gs...@lyra.org>.
Wow! This all sounds great.
Is it possible to get a partial checkin? That'll let us review pieces as
they go (easier to do a small bit, than a huge one), and you won't have to
worry about tracking other changes to the build system.
On Mon, Feb 12, 2001 at 11:30:47PM -0800, Roy T. Fielding wrote:
> Just a heads-up. I am still working on simplifying the build scripts.
> More changes are required for httpd than anything else, though I'd also
> like to streamline, name-protect, and make consistent the apr stuff.
Can we do this in a couple steps?
>...
> * make each "top-most" buildconf.sh set up the subdirectory configures
> directly with autoheader and autoconf, rather than running each of
> their buildconf.sh scripts. This will remove most of the redundant
> libtool and configure checks, force the whole tree to be built with a
> consistent set of flags, and allow each independent tree's buildconf.sh
> to be specialized for standalone builds of that tree.
Not sure about this one. Are you talking about APR building a libtool, and
having the other pieces just use APR's copy?
>...
> * modify all of the Makefile.in files to use the new @VARS@
I'm presuming that your @VARS@ is intended to replace config_vars.mk. Why
put it into each Makefile.in? Couldn't the @VARS@ just go into rules.mk.in?
[ note that Sascha used config_vars.mk to avoid the additional dozens of
substitutions at the end of the configure process. Running all of those
substitutions over all the files takes a good chunk of time. compressing
them down to a single @VARS@ substitution ought to do the trick, too. ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
I've finally got most of my sandbox configure changes checked-in,
but still haven't made the most significant changes:
* APR's configure should be called first to define everything and
generate an apr_make_vars.mk + apr_make_rules.mk in apr/include,
since this will be needed by any program that wants to build
from an installed APR library. We might want to install the
entire apr/build directory. *shrug*
* APR_ADDTO probably shouldn't be exporting variables -- this is
resulting in many repeated parameters on compiles/links.
* APR_PRELOAD should only be called by APR -- other configures
should inline the apr_make_vars.mk (what is now APRVARS) and
override whatever is in their environment. It isn't safe to
build APR clients with a set of compile and link flags
different from those used to build APR.
* Everywhere that we screw with CFLAGS, CPPFLAGS, LDFLAGS, etc.,
needs to be fixed so that we only temporarily modify them for
tests and save ONLY the modifications in EXTRA_*.
* The GNU Makefile standards need to be adhered to in all use
of standard variables and target names -- right now we aren't
even close (CFLAGS is often set with preprocessor defines and
distclean is cleaning too much and extraclean is only defined
within APR). Likewise, the standard names like CFLAGS should
be reserved for environment user-defined flags that can
override any of the ones we create with configure (i.e., they
must appear *after* the other variables on the command lines).
* buildconf needs to be modularized in each distribution
* httpd buildconf needs to be rewritten to eliminate the build.mk
spaghetti -- I've already done this in my sandbox, but it requires
more of the above before I can commit it.
* modify all of the Makefile.in files to use the new $(variables)
* libtoolize --automake --copy
* ./buildconf --disable-libtool [making it an option]
* fix dependencies so that they are created by configure
I have to do a brain swap now and prepare for the Wednesday board meeting,
so if anyone wants to do stuff to configure now is a good time. I won't
lose any work at this point.
....Roy
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
I've finally got most of my sandbox configure changes checked-in,
but still haven't made the most significant changes:
* APR's configure should be called first to define everything and
generate an apr_make_vars.mk + apr_make_rules.mk in apr/include,
since this will be needed by any program that wants to build
from an installed APR library. We might want to install the
entire apr/build directory. *shrug*
* APR_ADDTO probably shouldn't be exporting variables -- this is
resulting in many repeated parameters on compiles/links.
* APR_PRELOAD should only be called by APR -- other configures
should inline the apr_make_vars.mk (what is now APRVARS) and
override whatever is in their environment. It isn't safe to
build APR clients with a set of compile and link flags
different from those used to build APR.
* Everywhere that we screw with CFLAGS, CPPFLAGS, LDFLAGS, etc.,
needs to be fixed so that we only temporarily modify them for
tests and save ONLY the modifications in EXTRA_*.
* The GNU Makefile standards need to be adhered to in all use
of standard variables and target names -- right now we aren't
even close (CFLAGS is often set with preprocessor defines and
distclean is cleaning too much and extraclean is only defined
within APR). Likewise, the standard names like CFLAGS should
be reserved for environment user-defined flags that can
override any of the ones we create with configure (i.e., they
must appear *after* the other variables on the command lines).
* buildconf needs to be modularized in each distribution
* httpd buildconf needs to be rewritten to eliminate the build.mk
spaghetti -- I've already done this in my sandbox, but it requires
more of the above before I can commit it.
* modify all of the Makefile.in files to use the new $(variables)
* libtoolize --automake --copy
* ./buildconf --disable-libtool [making it an option]
* fix dependencies so that they are created by configure
I have to do a brain swap now and prepare for the Wednesday board meeting,
so if anyone wants to do stuff to configure now is a good time. I won't
lose any work at this point.
....Roy
Re: build blues
Posted by Greg Stein <gs...@lyra.org>.
Wow! This all sounds great.
Is it possible to get a partial checkin? That'll let us review pieces as
they go (easier to do a small bit, than a huge one), and you won't have to
worry about tracking other changes to the build system.
On Mon, Feb 12, 2001 at 11:30:47PM -0800, Roy T. Fielding wrote:
> Just a heads-up. I am still working on simplifying the build scripts.
> More changes are required for httpd than anything else, though I'd also
> like to streamline, name-protect, and make consistent the apr stuff.
Can we do this in a couple steps?
>...
> * make each "top-most" buildconf.sh set up the subdirectory configures
> directly with autoheader and autoconf, rather than running each of
> their buildconf.sh scripts. This will remove most of the redundant
> libtool and configure checks, force the whole tree to be built with a
> consistent set of flags, and allow each independent tree's buildconf.sh
> to be specialized for standalone builds of that tree.
Not sure about this one. Are you talking about APR building a libtool, and
having the other pieces just use APR's copy?
>...
> * modify all of the Makefile.in files to use the new @VARS@
I'm presuming that your @VARS@ is intended to replace config_vars.mk. Why
put it into each Makefile.in? Couldn't the @VARS@ just go into rules.mk.in?
[ note that Sascha used config_vars.mk to avoid the additional dozens of
substitutions at the end of the configure process. Running all of those
substitutions over all the files takes a good chunk of time. compressing
them down to a single @VARS@ substitution ought to do the trick, too. ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> We can't use --force. config.guess and config.sub are not stock in our
> tree.
Brilliant. I see it isn't up-to-date with recent autoconf either.
It looks like the only changes we made that are not obsoleted by
the newer autoconf release are the ones for OS/2 emx.
A point of order: committing a change to some other group's standard
file which happens to reside in our tree REQUIRES comment blocks
surrounding the change indicating when and why the change was made.
....Roy
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> We can't use --force. config.guess and config.sub are not stock in our
> tree.
Brilliant. I see it isn't up-to-date with recent autoconf either.
It looks like the only changes we made that are not obsoleted by
the newer autoconf release are the ones for OS/2 emx.
A point of order: committing a change to some other group's standard
file which happens to reside in our tree REQUIRES comment blocks
surrounding the change indicating when and why the change was made.
....Roy
Re: build blues
Posted by rb...@covalent.net.
On Tue, 13 Feb 2001 rbb@covalent.net wrote:
> On Tue, 13 Feb 2001, Greg Stein wrote:
>
> > On Tue, Feb 13, 2001 at 01:46:49PM -0800, Roy T. Fielding wrote:
> > >...
> > > > > * libtoolize --automake --copy --force
> > > > > [the only way we ever want to call libtoolize]
> > > >
> > > > why --automake?
> > >
> > > It is the option libtoolize is given to tell it to shut up because we
> > > are acting like automake (which we are). BTW, the --copy means you
> > > can remove the rm and recopy lines from the tarball builder.
> >
> > Note that we were already using --copy in APR(UTIL).
> >
> > Roy: the --force wasn't added to APR because we had some private copies of
> > two of the libtool files. I'm fine with tossing those if ours were
> > approximately the same, but be careful with that force.
>
> We can't use --force. config.guess and config.sub are not stock in our
> tree.
That's probably a bit cryptic. We don't have stock files, because we have
extra definitions for Darwin, and OS/2.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: build blues
Posted by rb...@covalent.net.
On Tue, 13 Feb 2001 rbb@covalent.net wrote:
> On Tue, 13 Feb 2001, Greg Stein wrote:
>
> > On Tue, Feb 13, 2001 at 01:46:49PM -0800, Roy T. Fielding wrote:
> > >...
> > > > > * libtoolize --automake --copy --force
> > > > > [the only way we ever want to call libtoolize]
> > > >
> > > > why --automake?
> > >
> > > It is the option libtoolize is given to tell it to shut up because we
> > > are acting like automake (which we are). BTW, the --copy means you
> > > can remove the rm and recopy lines from the tarball builder.
> >
> > Note that we were already using --copy in APR(UTIL).
> >
> > Roy: the --force wasn't added to APR because we had some private copies of
> > two of the libtool files. I'm fine with tossing those if ours were
> > approximately the same, but be careful with that force.
>
> We can't use --force. config.guess and config.sub are not stock in our
> tree.
That's probably a bit cryptic. We don't have stock files, because we have
extra definitions for Darwin, and OS/2.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: build blues
Posted by rb...@covalent.net.
On Tue, 13 Feb 2001, Greg Stein wrote:
> On Tue, Feb 13, 2001 at 01:46:49PM -0800, Roy T. Fielding wrote:
> >...
> > > > * libtoolize --automake --copy --force
> > > > [the only way we ever want to call libtoolize]
> > >
> > > why --automake?
> >
> > It is the option libtoolize is given to tell it to shut up because we
> > are acting like automake (which we are). BTW, the --copy means you
> > can remove the rm and recopy lines from the tarball builder.
>
> Note that we were already using --copy in APR(UTIL).
>
> Roy: the --force wasn't added to APR because we had some private copies of
> two of the libtool files. I'm fine with tossing those if ours were
> approximately the same, but be careful with that force.
We can't use --force. config.guess and config.sub are not stock in our
tree.
Ryan
>
> (APRUTIL uses --force because it never had its own copies for better or
> worse)
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: build blues
Posted by rb...@covalent.net.
On Tue, 13 Feb 2001, Greg Stein wrote:
> On Tue, Feb 13, 2001 at 01:46:49PM -0800, Roy T. Fielding wrote:
> >...
> > > > * libtoolize --automake --copy --force
> > > > [the only way we ever want to call libtoolize]
> > >
> > > why --automake?
> >
> > It is the option libtoolize is given to tell it to shut up because we
> > are acting like automake (which we are). BTW, the --copy means you
> > can remove the rm and recopy lines from the tarball builder.
>
> Note that we were already using --copy in APR(UTIL).
>
> Roy: the --force wasn't added to APR because we had some private copies of
> two of the libtool files. I'm fine with tossing those if ours were
> approximately the same, but be careful with that force.
We can't use --force. config.guess and config.sub are not stock in our
tree.
Ryan
>
> (APRUTIL uses --force because it never had its own copies for better or
> worse)
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: build blues
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 13, 2001 at 01:46:49PM -0800, Roy T. Fielding wrote:
>...
> > > * libtoolize --automake --copy --force
> > > [the only way we ever want to call libtoolize]
> >
> > why --automake?
>
> It is the option libtoolize is given to tell it to shut up because we
> are acting like automake (which we are). BTW, the --copy means you
> can remove the rm and recopy lines from the tarball builder.
Note that we were already using --copy in APR(UTIL).
Roy: the --force wasn't added to APR because we had some private copies of
two of the libtool files. I'm fine with tossing those if ours were
approximately the same, but be careful with that force.
(APRUTIL uses --force because it never had its own copies for better or
worse)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: build blues
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 13, 2001 at 01:46:49PM -0800, Roy T. Fielding wrote:
>...
> > > * libtoolize --automake --copy --force
> > > [the only way we ever want to call libtoolize]
> >
> > why --automake?
>
> It is the option libtoolize is given to tell it to shut up because we
> are acting like automake (which we are). BTW, the --copy means you
> can remove the rm and recopy lines from the tarball builder.
Note that we were already using --copy in APR(UTIL).
Roy: the --force wasn't added to APR because we had some private copies of
two of the libtool files. I'm fine with tossing those if ours were
approximately the same, but be careful with that force.
(APRUTIL uses --force because it never had its own copies for better or
worse)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> > * merged apr-conf.m4 and apr_common.m4 into build/acinclude.m4
> > and name-protected all of the macro names
> > -- have not yet name-protected the variables within the macros
>
> Those two files had two very different uses. The first is used for APR
> itself, and is a bunch of macros that no application using APR should need
> or even have to think about. The second is a set of macros that APR
> provides for applications. I would like to see these kept separate,
> because it makes it much easier for application programmers to locate the
> macros they want to use.
Well, that explains why they were created in the first place (would
have been useful to document that in the files), but that certainly
isn't the case for their contents. Both had mixed internal and
external macros. Regardless, the notion that some macros are only
useful for APR and others for its clients just doesn't hold up in
practice -- clients need to know what APR is doing for configure,
which means finding where the macros are defined, which means locating
the macros in one place. Splitting them up by type of macro would
make sense (like apr_pthreads.m4 and hints.m4).
> > * removed some unused macros
>
> such as?
MY_TRY_RUN and another macro which could only be used once as
part of the MM config (and thus was moved inline to configure.in).
> > * libtoolize --automake --copy --force
> > [the only way we ever want to call libtoolize]
>
> why --automake?
It is the option libtoolize is given to tell it to shut up because we
are acting like automake (which we are). BTW, the --copy means you
can remove the rm and recopy lines from the tarball builder.
> > All of the above is done for apr and it is building fine. What I still
> > need to do is
> >
> > * make each "top-most" buildconf.sh set up the subdirectory configures
> > directly with autoheader and autoconf, rather than running each of
> > their buildconf.sh scripts. This will remove most of the redundant
> > libtool and configure checks, force the whole tree to be built with a
> > consistent set of flags, and allow each independent tree's buildconf.sh
> > to be specialized for standalone builds of that tree.
>
> Each subdir will still run stand-alone, correct? There is a part of me
> that dislikes this, because it sounds like it will be possible to
> configure Apache without running APR's buildconf script, which means that
> any bugs in APR's buildconf script are likely to be hidden from a lot of
> the APR developers.
That is a hazard, but buildconf itself should be very small.
I think it is the only way for clients of APR to ensure that their
own builds are consistent (those that don't care can just call
APR's buildconf). Perhaps more importantly, it makes our
build tree behave more like a traditional autoconf setup, which
should reduce some of the hair-pulling experienced with adjusting
configure for portability.
I wish I could understand why libtool is so archaic. Why isn't it
just an autoconf macro that sets variables and defines post-process
macros?
....Roy
Re: build blues
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> > * merged apr-conf.m4 and apr_common.m4 into build/acinclude.m4
> > and name-protected all of the macro names
> > -- have not yet name-protected the variables within the macros
>
> Those two files had two very different uses. The first is used for APR
> itself, and is a bunch of macros that no application using APR should need
> or even have to think about. The second is a set of macros that APR
> provides for applications. I would like to see these kept separate,
> because it makes it much easier for application programmers to locate the
> macros they want to use.
Well, that explains why they were created in the first place (would
have been useful to document that in the files), but that certainly
isn't the case for their contents. Both had mixed internal and
external macros. Regardless, the notion that some macros are only
useful for APR and others for its clients just doesn't hold up in
practice -- clients need to know what APR is doing for configure,
which means finding where the macros are defined, which means locating
the macros in one place. Splitting them up by type of macro would
make sense (like apr_pthreads.m4 and hints.m4).
> > * removed some unused macros
>
> such as?
MY_TRY_RUN and another macro which could only be used once as
part of the MM config (and thus was moved inline to configure.in).
> > * libtoolize --automake --copy --force
> > [the only way we ever want to call libtoolize]
>
> why --automake?
It is the option libtoolize is given to tell it to shut up because we
are acting like automake (which we are). BTW, the --copy means you
can remove the rm and recopy lines from the tarball builder.
> > All of the above is done for apr and it is building fine. What I still
> > need to do is
> >
> > * make each "top-most" buildconf.sh set up the subdirectory configures
> > directly with autoheader and autoconf, rather than running each of
> > their buildconf.sh scripts. This will remove most of the redundant
> > libtool and configure checks, force the whole tree to be built with a
> > consistent set of flags, and allow each independent tree's buildconf.sh
> > to be specialized for standalone builds of that tree.
>
> Each subdir will still run stand-alone, correct? There is a part of me
> that dislikes this, because it sounds like it will be possible to
> configure Apache without running APR's buildconf script, which means that
> any bugs in APR's buildconf script are likely to be hidden from a lot of
> the APR developers.
That is a hazard, but buildconf itself should be very small.
I think it is the only way for clients of APR to ensure that their
own builds are consistent (those that don't care can just call
APR's buildconf). Perhaps more importantly, it makes our
build tree behave more like a traditional autoconf setup, which
should reduce some of the hair-pulling experienced with adjusting
configure for portability.
I wish I could understand why libtool is so archaic. Why isn't it
just an autoconf macro that sets variables and defines post-process
macros?
....Roy
Re: build blues
Posted by rb...@covalent.net.
> * merged apr-conf.m4 and apr_common.m4 into build/acinclude.m4
> and name-protected all of the macro names
> -- have not yet name-protected the variables within the macros
Those two files had two very different uses. The first is used for APR
itself, and is a bunch of macros that no application using APR should need
or even have to think about. The second is a set of macros that APR
provides for applications. I would like to see these kept separate,
because it makes it much easier for application programmers to locate the
macros they want to use.
> * removed some unused macros
such as?
> * libtoolize --automake --copy --force
> [the only way we ever want to call libtoolize]
why --automake?
> All of the above is done for apr and it is building fine. What I still
> need to do is
>
> * make each "top-most" buildconf.sh set up the subdirectory configures
> directly with autoheader and autoconf, rather than running each of
> their buildconf.sh scripts. This will remove most of the redundant
> libtool and configure checks, force the whole tree to be built with a
> consistent set of flags, and allow each independent tree's buildconf.sh
> to be specialized for standalone builds of that tree.
Each subdir will still run stand-alone, correct? There is a part of me
that dislikes this, because it sounds like it will be possible to
configure Apache without running APR's buildconf script, which means that
any bugs in APR's buildconf script are likely to be hidden from a lot of
the APR developers.
Other than those few comments, this is awesome.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: build blues
Posted by rb...@covalent.net.
> * merged apr-conf.m4 and apr_common.m4 into build/acinclude.m4
> and name-protected all of the macro names
> -- have not yet name-protected the variables within the macros
Those two files had two very different uses. The first is used for APR
itself, and is a bunch of macros that no application using APR should need
or even have to think about. The second is a set of macros that APR
provides for applications. I would like to see these kept separate,
because it makes it much easier for application programmers to locate the
macros they want to use.
> * removed some unused macros
such as?
> * libtoolize --automake --copy --force
> [the only way we ever want to call libtoolize]
why --automake?
> All of the above is done for apr and it is building fine. What I still
> need to do is
>
> * make each "top-most" buildconf.sh set up the subdirectory configures
> directly with autoheader and autoconf, rather than running each of
> their buildconf.sh scripts. This will remove most of the redundant
> libtool and configure checks, force the whole tree to be built with a
> consistent set of flags, and allow each independent tree's buildconf.sh
> to be specialized for standalone builds of that tree.
Each subdir will still run stand-alone, correct? There is a part of me
that dislikes this, because it sounds like it will be possible to
configure Apache without running APR's buildconf script, which means that
any bugs in APR's buildconf script are likely to be hidden from a lot of
the APR developers.
Other than those few comments, this is awesome.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------