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 22:55:32 UTC
Getting rid of '$top_builddir' in Makefile.in (was: Problem with r32409 (fix for 'BSD make' compatibility).)
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: 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