makefile improvements

[Ben Pfaff]

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.

--
Ben Pfaff
http://benpfaff.org


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[John Darrington-3]

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 ??




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).



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.


J'

--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.






_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Ben Pfaff]

John Darrington <john@...> 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


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Ben Pfaff]

John Darrington <john@...> 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


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[John Darrington-3]

On Mon, Oct 12, 2009 at 08:56:08AM -0700, Ben Pfaff wrote:

     >   $(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?

Is that something we can change?  Do we really need pspp.pot to be in
the tarball?  If not, then I guess we will indeed have to cope with
both locations.  And that is of course why the VPATH feature and the
$< variable was invented.

J'
     

--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.




_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Ben Pfaff]

John Darrington <john@...> writes:

> On Mon, Oct 12, 2009 at 08:56:08AM -0700, Ben Pfaff wrote:
>
>      >   $(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?
>
> Is that something we can change?  Do we really need pspp.pot to be in
> the tarball?  

I think that translationproject.org needs it: when I send them a
new tarball for translation, they extract pspp.pot from it.  At
least, I think that's how it works.

> If not, then I guess we will indeed have to cope with both
> locations.  And that is of course why the VPATH feature and the
> $< variable was invented.

Yes, obviously.  But I'd like to support BSD make here, and it
doesn't support $< for target rules, and I don't see a way to
write this as an implicit rule.
--
Ben Pfaff
http://benpfaff.org


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Ben Pfaff]

John Darrington <john@...> writes:

> On Mon, Oct 12, 2009 at 08:56:08AM -0700, Ben Pfaff wrote:
>
>      >   $(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?
>
> Is that something we can change?  Do we really need pspp.pot to be in
> the tarball?  If not, then I guess we will indeed have to cope with
> both locations.  And that is of course why the VPATH feature and the
> $< variable was invented.

I think I've found a satisfactory solution that avoids the need
to search for the path by hand.  POSIX requires $? to work even
though it does not require $< to work.  Since there is only one
target in this case, $? is always equivalent to $<.

The autoconf manual actually mentions this.  I had forgotten that
it had a chapter on VPATH:

       A simple workaround, and good practice anyway, is to use `$?' and
    `$@' when possible:

         VPATH = ../pkg/src
         f.c: if.c
                 cp $? $@

    but this does not generalize well to commands with multiple
    prerequisites.

We still do need to distribute pspp.pot, but this is easier to
read than searching by hand.
--
Ben Pfaff
http://benpfaff.org


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Ben Pfaff]

I've pushed a revised "makefiles" branch that uses $? in place of
$< for the rules where this is possible.  BSD make seems to be OK
with this.

What do you think of the new version?
--
Ben Pfaff
http://benpfaff.org


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[John Darrington-3]

It looks fine to me.  I haven't tested it.

We should run make distcheck before merging this.

J'

On Mon, Oct 12, 2009 at 08:50:31PM -0700, Ben Pfaff wrote:
     I've pushed a revised "makefiles" branch that uses $? in place of
     $< for the rules where this is possible.  BSD make seems to be OK
     with this.
     
     What do you think of the new version?
     --
     Ben Pfaff
     http://benpfaff.org
     
     
     _______________________________________________
     pspp-dev mailing list
     pspp-dev@...
     http://lists.gnu.org/mailman/listinfo/pspp-dev

--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.




_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev

[Ben Pfaff]

It passed "make distcheck" cleanly, so I pushed it to master.

John Darrington <john@...> writes:

> It looks fine to me.  I haven't tested it.
>
> We should run make distcheck before merging this.
>
> J'
>
> On Mon, Oct 12, 2009 at 08:50:31PM -0700, Ben Pfaff wrote:
>      I've pushed a revised "makefiles" branch that uses $? in place of
>      $< for the rules where this is possible.  BSD make seems to be OK
>      with this.
>      
>      What do you think of the new version?
>      --
>      Ben Pfaff
>      http://benpfaff.org
>      
>      
>      _______________________________________________
>      pspp-dev mailing list
>      pspp-dev@...
>      http://lists.gnu.org/mailman/listinfo/pspp-dev

--
Peter Seebach on managing engineers:
"It's like herding cats, only most of the engineers are already
 sick of laser pointers."


_______________________________________________
pspp-dev mailing list
pspp-dev@...
http://lists.gnu.org/mailman/listinfo/pspp-dev