You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Mo DeJong <md...@cygnus.com> on 2000/12/15 10:02:29 UTC
Patch to fix dirs when builddir != srcdir
Hello.
Here is a small patch that fixes up a couple of problems that
cause the configure script to break when run in a build
directory that is not the same as the source directory.
It also uses $MKDIR not $MKDIR -p, the -p thing is an
error, it ends up making a directory named -p in the
build dir.
cheers
Mo DeJong
Red Hat Inc
Index: aclocal.m4
===================================================================
RCS file: /home/cvspublic/apr/aclocal.m4,v
retrieving revision 1.34
diff -u -r1.34 aclocal.m4
--- aclocal.m4 2000/12/06 13:08:27 1.34
+++ aclocal.m4 2000/12/15 08:58:33
@@ -328,7 +328,7 @@
AC_DEFUN(APR_PREPARE_MM_DIR,[
dnl #----------------------------- Prepare mm directory for VPATH support
if test -n "$USE_MM" && test -n "$USE_VPATH"; then
- test -d $mm_dir || $MKDIR -p $mm_dir
+ test -d $mm_dir || $MKDIR $mm_dir
for i in shtool config.guess config.sub fbtool ltconfig \
ltmain.sh mm_vers.c; do
Index: configure.in
===================================================================
RCS file: /home/cvspublic/apr/configure.in,v
retrieving revision 1.188
diff -u -r1.188 configure.in
--- configure.in 2000/12/13 22:30:19 1.188
+++ configure.in 2000/12/15 08:58:34
@@ -28,6 +28,12 @@
abs_helpersdir=$abs_srcdir/helpers
MKDIR=$abs_helpersdir/mkdir.sh
+
+dnl # This is a small hack that is needed because old versions
+dnl # of autoconf do not do a mkdir -p for AC_CONFIG_HEADER.
+dir=include/arch/unix
+test -d $dir || $MKDIR $dir
+
if test "$abs_builddir" != "$abs_srcdir"; then
USE_VPATH=1
fi
@@ -801,7 +807,7 @@
SUBDIRS="lib strings passwd tables "
for dir in $MODULES
do
- test -d $dir || $MKDIR -p $dir
+ test -d $dir || $MKDIR $dir
if test -f $srcdir/$dir/$OSDIR/Makefile.in; then
MAKEFILE2="$MAKEFILE2 $dir/$OSDIR/Makefile "
SUBDIRS="$SUBDIRS $dir/$OSDIR "
Re: Patch to fix dirs when builddir != srcdir
Posted by Sascha Schumann <sa...@schumann.cx>.
> Sascha is being obtuse, when he should have simply said what he meant. That
> would have kept the discussion much cleaner (shame on you, Sascha).
If I say "X does not work in context Y", it does not
translate to "I don't like X".
What is so unclear in that sentence? Were people overwhelmed
by performing variable substitution?
- Sascha
Re: Patch to fix dirs when builddir != srcdir
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 15, 2000 at 05:59:14PM -0800, Mo DeJong wrote:
> On Sat, 16 Dec 2000, Sascha Schumann wrote:
>...
> > In my last email, I tried to communicate to you that you are
> > putting words into my mouth. Nobody likes that, especially if
> > you get it wrong. You have now succeeded in getting things
> > wrong again (no, I did not defend the choice of Perl and
> > never accused you of being anti-Perl, nor did I ever say that
> > I dislike automake or GNU make).
>...
> Funny, that is what I thought you were doing. Email
> is not a very good medium to discern intent, so I will
> try harder to not read things into what you write.
Sascha is being obtuse, when he should have simply said what he meant. That
would have kept the discussion much cleaner (shame on you, Sascha).
What he was trying to say, and what that Perl advocacy document stated, was
simply: choosing *not* to use a tool, does not imply that the tool is bad or
that it is disliked. It simply means that it was not chosen for that
particular task.
In this case, Sascha stated that automake was not chosen because it is a bit
heavy for APR, and that automake doesn't apply well to APR's flexibility.
Whether that is true or not is debatable :-), but he certainly didn't say he
disliked automake. You inferred that, he pointed you at that advocacy
document to try and show you that "not to choose" is not the same as
"dislike".
Personally, I dislike Perl. Immensely. But it solved our problem quite
readily (re: apr.exports). I believe that we should probably package that
file, rather than let end-users build it (thus, reducing the needs for the
build). But it would be even better if we could toss Perl and use awk or
something for that step.
And, btw, on "ignoring patches": I don't think we're ignoring your patches
at all. We had a discussion on autogen.sh and the benefits of changing over
to use that name didn't seem to be all that large. That isn't a rejection --
that is due consideration and a choice not to change.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
win32 users (was: Re: Patch to fix dirs when builddir != srcdir)
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Dec 16, 2000 at 03:06:24PM -0800, Mo DeJong wrote:
>...
> How do win32 users run the ./configure script without downloading
> Cygwin? Also, have you tried recent versions of Cygwin? The old
> install process really sucked, but new versions have a nice
> GUI installer that downloads all the packages over the net
> automatically. It is really easy to install, which seems to
> have been users main complaint.
Win32 users don't use ./configure. They use makefiles, *.dsp, and *.dsw.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Patch to fix dirs when builddir != srcdir
Posted by Mo DeJong <md...@cygnus.com>.
Here is another patch that fixes the RUN_SUBDIR_CONFIG_NOW
macro when it is run from the build directory and the
macro gets included into a configure.in from another
project. The problem was the the system did not know
where the helpers dir was.
Index: aclocal.m4
===================================================================
RCS file: /home/cvspublic/apr/aclocal.m4,v
retrieving revision 1.35
diff -u -r1.35 aclocal.m4
--- aclocal.m4 2000/12/15 16:56:51 1.35
+++ aclocal.m4 2000/12/16 22:57:11
@@ -328,7 +328,7 @@
AC_DEFUN(APR_PREPARE_MM_DIR,[
dnl #----------------------------- Prepare mm directory for VPATH support
if test -n "$USE_MM" && test -n "$USE_VPATH"; then
- test -d $mm_dir || $MKDIR $mm_dir
+ test -d $mm_dir || APR_MKDIR($mm_dir)
for i in shtool config.guess config.sub fbtool ltconfig \
ltmain.sh mm_vers.c; do
Index: apr_common.m4
===================================================================
RCS file: /home/cvspublic/apr/apr_common.m4,v
retrieving revision 1.9
diff -u -r1.9 apr_common.m4
--- apr_common.m4 2000/11/29 23:11:21 1.9
+++ apr_common.m4 2000/12/16 22:57:11
@@ -1,4 +1,39 @@
dnl
+dnl APR_MKDIR(dir)
+dnl
+dnl This macro works like `mkdir -p $dir' on systems that do not
+dnl support the -p flag to mkdir
+dnl
+dnl Based on `mkinstalldirs' from Noah Friedman <fr...@prep.ai.mit.edu>
+dnl as of 1994-03-25, which was placed in the Public Domain.
+dnl Cleaned up for Apache's Autoconf-style Interface (APACI)
+dnl by Ralf S. Engelschall <rs...@apache.org>
+
+AC_DEFUN(APR_MKDIR, [
+ umask_saved=`umask`
+ umask 022
+
+ dir=$1
+ dirlist=`echo ":$dir" |\
+ sed -e 's/^:\//%/' -e 's/^://' -e 's/\// /g' -e 's/^%/\//'`
+
+ pathcomp=
+ for d in $dirlist; do
+ pathcomp="$pathcomp$d"
+ case "$pathcomp" in
+ -* ) pathcomp=./$pathcomp ;;
+ esac
+ if test ! -d "$pathcomp"; then
+ #echo "mkdir $pathcomp" 1>&2
+ mkdir "$pathcomp"
+ fi
+ pathcomp="$pathcomp/"
+ done
+ echo "mkdir -p $1"
+ umask $umask_saved > /dev/null
+])
+
+dnl
dnl RUN_SUBDIR_CONFIG_NOW(dir [, sub-package-cmdline-args])
dnl
AC_DEFUN(RUN_SUBDIR_CONFIG_NOW, [
@@ -9,7 +44,7 @@
ac_popdir=`pwd`
ac_abs_srcdir=`(cd $srcdir/$1 && pwd)`
apr_config_subdirs="$1"
- test -d $1 || $srcdir/helpers/mkdir.sh $1
+ test -d $1 || APR_MKDIR($1)
cd $1
changequote(, )dnl
Index: configure.in
===================================================================
RCS file: /home/cvspublic/apr/configure.in,v
retrieving revision 1.189
diff -u -r1.189 configure.in
--- configure.in 2000/12/15 16:56:51 1.189
+++ configure.in 2000/12/16 22:57:11
@@ -26,7 +26,6 @@
dnl XXX This assumes that APR "lives" under Apache.
dnl XXX We'll need to fix this when we pull it out.
abs_helpersdir=$abs_srcdir/helpers
-MKDIR=$abs_helpersdir/mkdir.sh
if test "$abs_builddir" != "$abs_srcdir"; then
USE_VPATH=1
@@ -801,7 +800,7 @@
SUBDIRS="lib strings passwd tables "
for dir in $MODULES
do
- test -d $dir || $MKDIR $dir
+ test -d $dir || APR_MKDIR($dir)
if test -f $srcdir/$dir/$OSDIR/Makefile.in; then
MAKEFILE2="$MAKEFILE2 $dir/$OSDIR/Makefile "
SUBDIRS="$SUBDIRS $dir/$OSDIR "
@@ -826,7 +825,7 @@
done
dir=include/arch/unix
-test -d $dir || $MKDIR $dir
+test -d $dir || APR_MKDIR($dir)
AC_OUTPUT($MAKEFILE1 $MAKEFILE2 $MAKEFILE3 include/apr.h APRVARS,[
RE: Patch to fix dirs when builddir != srcdir
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Mo DeJong [mailto:mdejong@cygnus.com]
> Sent: Saturday, December 16, 2000 5:06 PM
>
> How do win32 users run the ./configure script without downloading
> Cygwin? Also, have you tried recent versions of Cygwin? The old
> install process really sucked, but new versions have a nice
> GUI installer that downloads all the packages over the net
> automatically. It is really easy to install, which seems to
> have been users main complaint.
It's all pre-config'ed as header.hw, corresponding to header.h.in.
The make simply copies the header.hw version, no text processing
in place today except at the end of apache's makefile.win
Re: Patch to fix dirs when builddir != srcdir
Posted by Mo DeJong <md...@cygnus.com>.
On Sat, 16 Dec 2000 rbb@covalent.net wrote:
>
> > > I would like to know why perl is used to determine how easy it
> > > would be to replace with something that has a better shot at
> > > being installed on every box that someone might want to build
> > > apr on.
> >
> > Feel free to provide an awk script which implements the
> > equivalent functionality.
>
> I used Perl because I wanted to learn Perl better. This is also not a
> simple question to answer, and using awk will not solve the problem
> here. Last I checked, Win32 does not have awk, and getting it requires
> that you actually download cygwin.
>
> The purpose of this script, is to allow all platforms to figure out what
> symbols are exported, currently just Unix is using this, but I fully
> expect AIX and Win32 to migrate to the .exports files soon. If you change
> this script to be an awk script, then anybody who decides to use APR on
> Win32 will also need to download cygwin. That is bad IMHO. Apache has
> required Perl to allow things to build properly for some time, and I do
> not believe it is unreasonable to require Perl for APR and apr-util.
>
> Ryan
How do win32 users run the ./configure script without downloading
Cygwin? Also, have you tried recent versions of Cygwin? The old
install process really sucked, but new versions have a nice
GUI installer that downloads all the packages over the net
automatically. It is really easy to install, which seems to
have been users main complaint.
Mo DeJong
Red Hat Inc
Re: Patch to fix dirs when builddir != srcdir
Posted by Sascha Schumann <sa...@schumann.cx>.
> I used Perl because I wanted to learn Perl better. This is also not a
> simple question to answer, and using awk will not solve the problem
> here. Last I checked, Win32 does not have awk, and getting it requires
> that you actually download cygwin.
That is not true. You can get the latest GNU awk version for
Win32 as a 500KB download:
ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/gwk306b.zip
The last time I used Perl for Win32 (3 years ago or so), it
was already at 3MB.
- Sascha
Re: Patch to fix dirs when builddir != srcdir
Posted by rb...@covalent.net.
> > I would like to know why perl is used to determine how easy it
> > would be to replace with something that has a better shot at
> > being installed on every box that someone might want to build
> > apr on.
>
> Feel free to provide an awk script which implements the
> equivalent functionality.
I used Perl because I wanted to learn Perl better. This is also not a
simple question to answer, and using awk will not solve the problem
here. Last I checked, Win32 does not have awk, and getting it requires
that you actually download cygwin.
The purpose of this script, is to allow all platforms to figure out what
symbols are exported, currently just Unix is using this, but I fully
expect AIX and Win32 to migrate to the .exports files soon. If you change
this script to be an awk script, then anybody who decides to use APR on
Win32 will also need to download cygwin. That is bad IMHO. Apache has
required Perl to allow things to build properly for some time, and I do
not believe it is unreasonable to require Perl for APR and apr-util.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Patch to fix dirs when builddir != srcdir
Posted by Mo DeJong <md...@cygnus.com>.
On Sat, 16 Dec 2000, Sascha Schumann wrote:
> > I would like to know why perl is used to determine how easy it
> > would be to replace with something that has a better shot at
> > being installed on every box that someone might want to build
> > apr on.
>
> Feel free to provide an awk script which implements the
> equivalent functionality.
Ok, as long as you are open to changing it, I am happy.
> > When I mentioned the autogen.sh thing, you claimed
> > that it was fine to use ./buildconf and that you did
> > not want to change it. Submitting patches that get
> > ignored is no fun.
>
> I think it would dramatically improve your chance to get
> your proposals accepted, if you would try to understand what
> your counterpart says.
>
> In my last email, I tried to communicate to you that you are
> putting words into my mouth. Nobody likes that, especially if
> you get it wrong. You have now succeeded in getting things
> wrong again (no, I did not defend the choice of Perl and
> never accused you of being anti-Perl, nor did I ever say that
> I dislike automake or GNU make).
>
> Thanks,
> - Sascha
Funny, that is what I thought you were doing. Email
is not a very good medium to discern intent, so I will
try harder to not read things into what you write.
cheers
Mo DeJong
Red Hat Inc
Re: Patch to fix dirs when builddir != srcdir
Posted by Sascha Schumann <sa...@schumann.cx>.
> I would like to know why perl is used to determine how easy it
> would be to replace with something that has a better shot at
> being installed on every box that someone might want to build
> apr on.
Feel free to provide an awk script which implements the
equivalent functionality.
> When I mentioned the autogen.sh thing, you claimed
> that it was fine to use ./buildconf and that you did
> not want to change it. Submitting patches that get
> ignored is no fun.
I think it would dramatically improve your chance to get
your proposals accepted, if you would try to understand what
your counterpart says.
In my last email, I tried to communicate to you that you are
putting words into my mouth. Nobody likes that, especially if
you get it wrong. You have now succeeded in getting things
wrong again (no, I did not defend the choice of Perl and
never accused you of being anti-Perl, nor did I ever say that
I dislike automake or GNU make).
Thanks,
- Sascha
Re: Patch to fix dirs when builddir != srcdir
Posted by Mo DeJong <md...@cygnus.com>.
On Sat, 16 Dec 2000, Sascha Schumann wrote:
> > Ok, so you don't like automake and gnu make.
>
> May I gently request that you read this article:
>
> http://www.perl.com/pub/2000/12/advocacy.html?wwwrrr_20001213.txt
I have read that article before, and no I am not on an anti-perl
kick or anything. I would like to know why perl is used to
determine how easy it would be to replace with something that
has a better shot at being installed on every box that someone
might want to build apr on. For example, Cygwin does not
come with Perl so that would throw a big wrench in the
process of bulding apr as I would need to download and
build perl first.
> This is an open source project; please quit whining about
> missing standard adherence. If you don't like something, feel
> free to submit patches.
>
> Thanks,
> - Sascha
How else would standards get implemented :)
When I mentioned the autogen.sh thing, you claimed
that it was fine to use ./buildconf and that you did
not want to change it. Submitting patches that get
ignored is no fun.
Mo DeJong
Red Hat Inc
Re: Patch to fix dirs when builddir != srcdir
Posted by Sascha Schumann <sa...@schumann.cx>.
> Ok, so you don't like automake and gnu make.
May I gently request that you read this article:
http://www.perl.com/pub/2000/12/advocacy.html?wwwrrr_20001213.txt
If I say "X does not work in context Y", it does not
translate to "I don't like X".
This is an open source project; please quit whining about
missing standard adherence. If you don't like something, feel
free to submit patches.
Thanks,
- Sascha
Re: Patch to fix dirs when builddir != srcdir
Posted by Mo DeJong <md...@cygnus.com>.
On Fri, 15 Dec 2000, Sascha Schumann wrote:
> > Could someone tell me why it was done this way? Is there
> > any reason we could not switch over to using automake?
>
> automake is unsuitable for projects with a large set of
> variables and/or Makefiles (because it shifts substitutions
> from make to sed which becomes annoingly slow quickly).
> Additionally, the dependency tracking is inherently build
> around GNU utilities.
Ok, so you don't like automake and gnu make.
> It is very likely that APR will switch to a more suitable
> build-system in the near future.
>
> I don't think there is anything currently which runs
> config.status automatically (I have not looked at it for
> quite some time though), so it should not fubar your build
> out of the blue.
>
> - Sascha
I run ./config.status and I expect it to work. Having a
configure script that does an extra subst after running
./config.status from inside the normal configure script
is just going to confuse people. I don't want to get
back into that discussion of what "standard" means.
I would hope that we could just agree that "does not
confuse the daylights out of people who are used
to working with autoconf and related tools" would
be something to shoot for. Sure, you could go off
and do it differently for your project, by why bother
being different?
Mo DeJong
Red Hat Inc
Re: Patch to fix dirs when builddir != srcdir
Posted by Sascha Schumann <sa...@schumann.cx>.
> Could someone tell me why it was done this way? Is there
> any reason we could not switch over to using automake?
automake is unsuitable for projects with a large set of
variables and/or Makefiles (because it shifts substitutions
from make to sed which becomes annoingly slow quickly).
Additionally, the dependency tracking is inherently build
around GNU utilities.
It is very likely that APR will switch to a more suitable
build-system in the near future.
I don't think there is anything currently which runs
config.status automatically (I have not looked at it for
quite some time though), so it should not fubar your build
out of the blue.
- Sascha
Re: Patch to fix dirs when builddir != srcdir
Posted by Mo DeJong <md...@cygnus.com>.
On Fri, 15 Dec 2000, Mo DeJong wrote:
> On Fri, 15 Dec 2000, Sascha Schumann wrote:
>
> > On Fri, 15 Dec 2000, Mo DeJong wrote:
> >
> > > Hello.
> > >
> > > Here is a small patch that fixes up a couple of problems that
> > > cause the configure script to break when run in a build
> > > directory that is not the same as the source directory.
> > > It also uses $MKDIR not $MKDIR -p, the -p thing is an
> > > error, it ends up making a directory named -p in the
> > > build dir.
> >
> > Applied. I've also taken the chance to fix some other VPATH
> > issues, so that APR builds now cleanly in a separate
> > directory. Thanks,
> >
> > - Sascha
This is a quick followup to my last message. I am now seeing
build problems when srcdir != builddir in the apr/shmem/unix/mm
and apr/shmem/unix dirs.
If I run from the toplevel, the error looks like:
make[1]: Entering directory `/usr/local/project/build/apr/shmem/unix'
gcc -DLINUX=2 -pthread -D_REENTRANT -c -I../../include
-I/home/mo/project/subversion/apr/shmem/unix/../../include -Imm
-I/home/mo/project/subversion/apr/shmem/unix/mm
/home/mo/project/subversion/apr/shmem/unix/shmem.c
rm -f libshmem.a
(cd mm && make libmm.la)
make[2]: Entering directory `/usr/local/project/build/apr/shmem/unix/mm'
make[2]: `/home/mo/project/subversion/apr/shmem/unix/mm/libmm.la' is up
to date.
make[2]: Leaving directory `/usr/local/project/build/apr/shmem/unix/mm'
cp mm/mm_global.o mm/mm_alloc.o mm/mm_core.o mm/mm_lib.o mm/mm_vers.o .
cp: mm/mm_global.o: No such file or directory
cp: mm/mm_alloc.o: No such file or directory
cp: mm/mm_core.o: No such file or directory
cp: mm/mm_lib.o: No such file or directory
cp: mm/mm_vers.o: No such file or directory
make[1]: *** [libshmem.a] Error 1
make[1]: Leaving directory `/usr/local/project/build/apr/shmem/unix'
make: *** [subdirs] Error 1
If you run in the apr/shmem/unix/mm dir, the error looks like:
mo(~/project/build/apr/shmem/unix/mm)% make
V1=`./shtool version -l c -d short mm_vers.c`; \
V2=`./shtool version -l c -d long mm_vers.c`; \
D=`./shtool version -l c -d long mm_vers.c | sed -e 's;.*(;;' -e
's;).*;;'`; \
pod2man --section=1 --center="Shared Memory Library" --release="$D"
--date="MM $V1" mm-config.pod |\
perl -p -e
's;^(\\\&\s+.+?)([Mm][Mm]_[a-zA-Z0-9_]+)(\(.+?)$;$1\\fB$2\\fR$3;' |\
sed -e "s;MM_VERSION_STR;$V2;" >mm-config.1
can't open mm-config.pod: No such file or directory at /usr/bin/pod2man
line 403.
./libtool --quiet --mode=compile gcc -c -DLINUX=2
-I/home/mo/project/subversion/apr/shmem/unix/mm/ -I.
/home/mo/project/subversion/apr/shmem/unix/mm/mm_test.c
./libtool --quiet --mode=link gcc -o mm_test mm_test.lo libmm.la
libtool: link: `libmm.la' is not a valid libtool archive
make: *** [mm_test] Error 1
After some poking around, I found that this error was
caused by the fact that I had also configured
and built apr in the src dir. Doing a "make distclean"
in the srcdir fixed things.
But, this raised another question, why on earth is perl
required just to build the package? This seems like a
major mistake. The build process should not require
anything other than sh, sed, and a couple of other utils
like uname. Putting in a dep for Perl, Python, Tcl, or
any other scripting language is a big mistake.
The good news is that I was able to build apr in a
build dir for the first time (Yeah!)
Mo DeJong
Red Hat Inc
Re: Patch to fix dirs when builddir != srcdir
Posted by Mo DeJong <md...@cygnus.com>.
On Fri, 15 Dec 2000, Sascha Schumann wrote:
> On Fri, 15 Dec 2000, Mo DeJong wrote:
>
> > Hello.
> >
> > Here is a small patch that fixes up a couple of problems that
> > cause the configure script to break when run in a build
> > directory that is not the same as the source directory.
> > It also uses $MKDIR not $MKDIR -p, the -p thing is an
> > error, it ends up making a directory named -p in the
> > build dir.
>
> Applied. I've also taken the chance to fix some other VPATH
> issues, so that APR builds now cleanly in a separate
> directory. Thanks,
>
> - Sascha
Great!
My next question is related to the way the configure script
seems to be doing extra substs that are not done when
you simply run ./config.status. Here is a quick example.
% cd ~/project/build/apr
% /home/mo/project/subversion/apr/configure
...
% cd network_io/unix
% make
gcc -DLINUX=2 -pthread -D_REENTRANT -c -I../../include
-I/home/mo/project/subversion/apr/network_io/unix/../../include
-I../../include/arch/unix
-I/home/mo/project/subversion/apr/network_io/unix/../../include/arch/unix
-I../../include/arch/unix
-I/home/mo/project/subversion/apr/network_io/unix/../../include/arch/unix
/home/mo/project/subversion/apr/network_io/unix/sockets.c
% cp Makefile Makefile.orig
% cd ../..
% ./config.status
...
% cd network_io/unix
% rm sockets.o
% make
make: *** No rule to make target `poll.o', needed by `all'. Stop.
Why you ask? Because the srcdir, VPATH, and -I$(srcdir) and
not getting put into the Makefile when ./config.status is run.
% diff -u Makefile.orig Makefile
--- Makefile.orig Fri Dec 15 13:33:22 2000
+++ Makefile Fri Dec 15 13:33:30 2000
@@ -1,6 +1,3 @@
-srcdir = /home/mo/project/subversion/apr/network_io/unix/
-VPATH = /home/mo/project/subversion/apr/network_io/unix/
-
# Generated automatically from Makefile.in by configure.
RM=rm
CC=gcc
@@ -11,7 +8,7 @@
INCDIR=../../include
OSDIR=$(INCDIR)/arch/unix
DEFOSDIR=$(INCDIR)/arch/unix
-INCLUDES=-I$(INCDIR) -I$(srcdir)$(INCDIR) -I$(OSDIR) -I$(srcdir)$(OSDIR)
-I$(DEFOSDIR) -I$(srcdir)$(DEFOSDIR)
+INCLUDES=-I$(INCDIR) -I$(OSDIR) -I$(DEFOSDIR)
MKDEP=../../helpers/mkdep.sh
The code that does this stuff is in configure.in:
dnl #----------------------------- Fixup Makefiles for VPATH support
changequote({,})
if test -n "$USE_VPATH"; then
if test -n "$USE_MM"; then
MAKEFILE3="$MAKEFILE3 $mm_dir/Makefile"
fi
for makefile in $MAKEFILE1 $MAKEFILE2 $MAKEFILE3; do
dir=`echo $makefile|sed 's%[^/][^/]*$%%'`
(cat <<EOF
srcdir = $abs_srcdir/$dir
VPATH = $abs_srcdir/$dir
EOF
) | cat - $makefile | \
sed \
-e 's#-I\($(INCDIR[0-9]*)\)#-I\1 -I$(srcdir)\1#g' \
-e 's#-I\($(OSDIR[0-9]*)\)#-I\1 -I$(srcdir)\1#g' \
-e 's#-I\($(DEFOSDIR[0-9]*)\)#-I\1 -I$(srcdir)\1#g' \
> tmp
cp tmp $makefile
done
I guess I just don't see why the VPATH and $(srcdir) stuff
is not put directly into the Makefile.in's and then substituted
in the normal way.
Could someone tell me why it was done this way? Is there
any reason we could not switch over to using automake?
Mo DeJong
Red Hat Inc
Re: Patch to fix dirs when builddir != srcdir
Posted by Sascha Schumann <sa...@schumann.cx>.
On Fri, 15 Dec 2000, Mo DeJong wrote:
> Hello.
>
> Here is a small patch that fixes up a couple of problems that
> cause the configure script to break when run in a build
> directory that is not the same as the source directory.
> It also uses $MKDIR not $MKDIR -p, the -p thing is an
> error, it ends up making a directory named -p in the
> build dir.
Applied. I've also taken the chance to fix some other VPATH
issues, so that APR builds now cleanly in a separate
directory. Thanks,
- Sascha