pspp-dev
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]