I've re-subjected this so Makefile.in fetishists will notice the thread.
Stefan Sperling <stsp_at_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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-28 00:55:52 CEST