You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@red-bean.com> on 2008/08/27 18:25:00 UTC
Problem with r32409 (fix for 'BSD make' compatibility).
I was just reviewing r32409 (last change in the STATUS file for 1.5.2),
and have a question about it:
> ------------------------------------------------------------------------
> r32409 | stsp | 2008-08-08 15:13:02 -0400 (Fri, 08 Aug 2008) | 40 lines
> Changed paths:
> M /trunk/build/generator/gen_make.py
>
> Fix an incompatibility with BSD make, which was introduced in r24293.
>
> Even though r24293 was meant to fix a compilation failure in the
> bindings when compiling Subversion from a different directory than
> where the source tree is located, this still didn't work for me.
>
> To illustrate, a command sequence like
>
> $ svn co https://svn.collab.net/repos/svn/trunk subversion
> $ mkdir obj
> $ cd obj
> $ ../subversion/configure --prefix= ...
> $ make
> $ make swig-py
>
> failed with:
> make: don't know how to make subversion/bindings/swig/python/svn_client.c. Stop
>
> It turned out to be a problem specific to BSD make.
> With GNU make, things worked fine.
>
> The problem was that in build-outputs.mk, the generated binding
> source files were preceeded with '$(top_builddir)/' when listed
> as targets, but did not have any prefix (i.e. were relative paths)
> when listed as dependencies. BSD make is apparently too naive to
> figure out that e.g. 'foo.c' and './foo.c' are meant to refer to
> the same file.
>
> Since '$(top_builddir)' is hardcoded to just '.' (a dot)
> at the top of Makefile.in, it is redundant and can be ommitted.
> As soon as the target and dependency paths matched, the problem
> went away. Turns out GNU make does not care either way, so this
> commit makes both make implementations happy.
Hmmm. So we've stopped including "$(top_builddir)/" as a prefix to
bindings source files listed as targets... This feels like a halfway
solution, though. Exactly one of the following two cases is true, i
think:
1. $top_builddir is conceivably useful, in which case we should
include it everywhere we might need it; after all, it might not
always be hardcoded to '.'
-OR-
2. $top_builddir is not useful (will *always* be hardcoded to '.'),
in which case, shouldn't we get rid of it entirely, instead of
just ceasing to use it in this one instance?
-Karl
> * build/generator/gen_make.py
> (Generator.write): Don't prefix the names of generated binding
> source files with '$(top_builddir)/' when listing them as target,
> because this confuses BSD make. When listed as dependencies,
> the files do not have this prefix either.
>
> Index: trunk/build/generator/gen_make.py
> ===================================================================
> --- trunk/build/generator/gen_make.py (revision 32408)
> +++ trunk/build/generator/gen_make.py (revision 32409)
> @@ -186,7 +186,7 @@
> source_dir = build_path_dirname(source)
> opts = self.swig.opts[objname.lang]
> if not self.release_mode:
> - self.ofile.write('$(top_builddir)/%s: %s\n' % (objname, deps) +
> + self.ofile.write('%s: %s\n' % (objname, deps) +
> '\t$(SWIG) $(SWIG_INCLUDES) %s ' % opts +
> '-o $@ $(top_srcdir)/%s\n' % source
> )
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting rid of '$top_builddir' in Makefile.in
Posted by Karl Fogel <kf...@red-bean.com>.
Stefan Sperling <st...@elego.de> writes:
>> Stefan Sperling <st...@elego.de> writes:
>> > The only case I can think of where top_builddir could be something
>> > other than '.' would be when running make from a different directory
>> > than where the generated Makefile resides. E.g. like so:
>> >
>> > cd /tmp && make -f ~/svn/Makefile
>> >
>> > In which case we'd have to be a bit smarter about setting top_builddir.
>> > But I don't expect anyone would need to compile Subversion like that.
>>
>> Well, we'd still have relative paths in all the places where we now have
>> $top_builddir, so even the above would still work.
>
> I don't understand why it "would still work".
>
> Since it does not work now, how can it still work after getting rid of
> $top_builddir?
I just mean that its behavior wouldn't change. A relative path from cwd
is still a relative path, whether prefixed with "./" or not.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting rid of '$top_builddir' in Makefile.in (was: Problem
with r32409 (fix for 'BSD make' compatibility).)
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Aug 27, 2008 at 06:55:32PM -0400, Karl Fogel wrote:
> I've re-subjected this so Makefile.in fetishists will notice the thread.
>
> Stefan Sperling <st...@elego.de> writes:
> > The only case I can think of where top_builddir could be something
> > other than '.' would be when running make from a different directory
> > than where the generated Makefile resides. E.g. like so:
> >
> > cd /tmp && make -f ~/svn/Makefile
> >
> > In which case we'd have to be a bit smarter about setting top_builddir.
> > But I don't expect anyone would need to compile Subversion like that.
>
> Well, we'd still have relative paths in all the places where we now have
> $top_builddir, so even the above would still work.
I don't understand why it "would still work".
Since it does not work now, how can it still work after getting rid of
$top_builddir?
stsp@ted [/tmp] $ make -f ~/svn/svn-trunk/Makefile
"/home/stsp/svn/svn-trunk/Makefile", line 303: Could not find ./build-outputs.mk
make: fatal errors encountered -- cannot continue
> Folks, does $top_builddir serve any purpose? If it does, let's put a
> comment there explaining it; if it doesn't, let's just get rid of it.
As already stated, +1.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting rid of '$top_builddir' in Makefile.in (was: Problem with r32409 (fix for 'BSD make' compatibility).)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Aug 27, 2008 at 3:55 PM, Karl Fogel <kf...@red-bean.com> wrote:
> Folks, does $top_builddir serve any purpose? If it does, let's put a
> comment there explaining it; if it doesn't, let's just get rid of it.
It's usually seen when you have recursive makefiles - which we haven't
had for a looong, looong time. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Getting rid of '$top_builddir' in Makefile.in (was: Problem with r32409 (fix for 'BSD make' compatibility).)
Posted by Karl Fogel <kf...@red-bean.com>.
I've re-subjected this so Makefile.in fetishists will notice the thread.
Stefan Sperling <st...@elego.de> writes:
> On Wed, Aug 27, 2008 at 02:25:00PM -0400, Karl Fogel wrote:
>> I was just reviewing r32409 (last change in the STATUS file for 1.5.2),
>> and have a question about it:
>
> Thanks for looking at this :)
>
>> Hmmm. So we've stopped including "$(top_builddir)/" as a prefix to
>> bindings source files listed as targets... This feels like a halfway
>> solution, though. Exactly one of the following two cases is true, i
>> think:
>>
>> 1. $top_builddir is conceivably useful, in which case we should
>> include it everywhere we might need it; after all, it might not
>> always be hardcoded to '.'
>>
>> -OR-
>>
>> 2. $top_builddir is not useful (will *always* be hardcoded to '.'),
>> in which case, shouldn't we get rid of it entirely, instead of
>> just ceasing to use it in this one instance?
>
> As far as I can tell, case 2 is true:
>
> $ svn cat https://svn.collab.net/repos/svn/trunk/Makefile.in \
> | grep top_builddir
> top_builddir = .
> INCLUDES = -I$(top_srcdir)/subversion/include -I$(top_builddir)/subversion \
> $
>
> To me, it looks like top_builddir is indeed just hardcoded to a dot.
> I'm not sure why we have that defined at all.
>
> 'svn blame Makefile.in' says top_builddir has been around at least
> since Subversion went self-hosting:
>
> 1 svn top_builddir = .
>
> So if nothing else breaks when it's removed, I'd say let's remove it.
>
> The only case I can think of where top_builddir could be something
> other than '.' would be when running make from a different directory
> than where the generated Makefile resides. E.g. like so:
>
> cd /tmp && make -f ~/svn/Makefile
>
> In which case we'd have to be a bit smarter about setting top_builddir.
> But I don't expect anyone would need to compile Subversion like that.
Well, we'd still have relative paths in all the places where we now have
$top_builddir, so even the above would still work.
Folks, does $top_builddir serve any purpose? If it does, let's put a
comment there explaining it; if it doesn't, let's just get rid of it.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with r32409 (fix for 'BSD make' compatibility).
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Aug 27, 2008 at 02:25:00PM -0400, Karl Fogel wrote:
> I was just reviewing r32409 (last change in the STATUS file for 1.5.2),
> and have a question about it:
>
Thanks for looking at this :)
> Hmmm. So we've stopped including "$(top_builddir)/" as a prefix to
> bindings source files listed as targets... This feels like a halfway
> solution, though. Exactly one of the following two cases is true, i
> think:
>
> 1. $top_builddir is conceivably useful, in which case we should
> include it everywhere we might need it; after all, it might not
> always be hardcoded to '.'
>
> -OR-
>
> 2. $top_builddir is not useful (will *always* be hardcoded to '.'),
> in which case, shouldn't we get rid of it entirely, instead of
> just ceasing to use it in this one instance?
As far as I can tell, case 2 is true:
$ svn cat https://svn.collab.net/repos/svn/trunk/Makefile.in \
| grep top_builddir
top_builddir = .
INCLUDES = -I$(top_srcdir)/subversion/include -I$(top_builddir)/subversion \
$
To me, it looks like top_builddir is indeed just hardcoded to a dot.
I'm not sure why we have that defined at all.
'svn blame Makefile.in' says top_builddir has been around at least
since Subversion went self-hosting:
1 svn top_builddir = .
So if nothing else breaks when it's removed, I'd say let's remove it.
The only case I can think of where top_builddir could be something
other than '.' would be when running make from a different directory
than where the generated Makefile resides. E.g. like so:
cd /tmp && make -f ~/svn/Makefile
In which case we'd have to be a bit smarter about setting top_builddir.
But I don't expect anyone would need to compile Subversion like that.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org