[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: makefile improvements
From: |
Ben Pfaff |
Subject: |
Re: makefile improvements |
Date: |
Mon, 12 Oct 2009 08:57:04 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
John Darrington <address@hidden> writes:
> On Sun, Oct 11, 2009 at 09:36:21PM -0700, Ben Pfaff wrote:
> I created a branch with improvements to the PSPP makefiles, named
> "makefiles". I'd appreciate it if you'd look it over and make
> comments before I merge anything into master.
>
> 1.
> po_CLEAN:
> @if test "$(srcdir)" != .; then \
> echo rm -f $(POFILES); \
> rm -f $(POFILES); \
> fi
>
> In principle this is fine, but I'm not sure that the test is very reliable.
> For example if the curreent directory is /home/john and srcdir is
> "/home/john"
> or "../john" then it'll give the wrong result. There are several other places
> in the makefiles where a similar trick is used. Perhaps we should do the
> test in configure, and define a conditional ??
The "configure" script is pretty careful to make sure that srcdir
is "." if "configure" is running from the source directory,
regardless of how the source directory was specified:
ac_pwd=`pwd` && test -n "$ac_pwd"
...
ac_abs_confdir=`(
cd "$srcdir" && test -r "./$ac_unique_file" || as_fn_error "$ac_msg"
pwd)`
# When building in place, set srcdir=.
if test "$ac_abs_confdir" = "$ac_pwd"; then
srcdir=.
fi
I'm not sure that we can really do better than that, although I
suppose defining a variable might make it 100% obvious why we're
testing srcdir.
> 2.
> $(POFILES): $(POTFILE)
> $(MSGMERGE) $(top_srcdir)/$@ $(top_srcdir)/$(POTFILE) -o $@
>
> $(POTFILE) is a generated file, so it will be in $(top_builddir) not
> $(top_srcdir).
I hadn't realize that.
When we make a distribution with "make dist", $(POTFILE) will be
distributed and thus it will be in the source directory. Does
this mean that we have to cope with both possible locations?
> 3.
> The $(VARIABLE) syntax is usually preferred, because it is possible for
> the user to override it at "make" time, whereas @VARIABLE@ is hardwired at
> "configure" time.
>
> I'm in two minds about whether this is an advantage or not.
I know that sometimes I want to override the name of a build tool
at "make" time, and that I can't do it if @VARIABLE@ is used.
For example, I might run something like "make CC='gcc -E'
tests/libpspp/ll-test.o" to get a preprocessor-expanded version
of tests/libpspp/ll-test.c. This only works because $(CC) is
used consistently in the makefiles.
--
"Writing is easy.
All you do is sit in front of a typewriter and open a vein."
--Walter Smith