Re: make distcheck fails for simple Makefile.am

2005-06-20 Thread Ralf Wildenhues
* Roger Leigh wrote on Sat, Jun 18, 2005 at 12:47:08PM CEST:
 
 In a simple Makefile.am:
 
 pamdir = /etc/pam.d
 pam_DATA = schroot
 EXTRA_DIST = $(pam_DATA)
 
 make distcheck fails:

Make that 
  pamdir = $(prefix)/etc/pam.d

but you really should be using sysconfdir:
  pamdir = $(sysconfdir)/pam.d

so that both the casual user and the distribution packager can easily
override the values: the former could do
  configure --sysconfdir=/etc   # rest goes under /usr/local
whereas the latter does
  configure --prefix=/

So no, this is not a bug in Automake.

Regards,
Ralf




Re: how to run a test file with command line options...

2005-06-20 Thread Harald Dunkel
Ed Hartnett wrote:
 Howdy all!
 
 If I have some tests, and want to run them with command line options,
 how do I do it?
 
 For example, I have to have a shell script to run tst_parallel below,
 because it needs to be called with the poe command, and some env vars
 set. In other cases, I need to call test program with some command
 line options.
 
 check_PROGRAMS = tst_parallel
 TESTS = run_par_test.sh
 
 Where run_par_test.sh is:
 
 MP_TASKS_PER_NODE=4 MP_PROCS=4 poe ./tst_parallel
 

Since Automake is based on Perl it should be pretty easy to do
some cgi-style replacement, e.g.

TESTS = MP_TASKS_PER_NODE=4%20MP_PROCS=4%20poe%20./tst_parallel

Pretty ugly and error-prone, of course, but it would be more or
less backward compatible, and better than nothing.


Justanidea. Regards

Harri




Re: how to run a test file with command line options...

2005-06-20 Thread Ralf Wildenhues
* Harald Dunkel wrote on Mon, Jun 20, 2005 at 10:11:05AM CEST:
 Ed Hartnett wrote:
  
  check_PROGRAMS = tst_parallel
  TESTS = run_par_test.sh
  
  Where run_par_test.sh is:
  
  MP_TASKS_PER_NODE=4 MP_PROCS=4 poe ./tst_parallel
 
 Since Automake is based on Perl it should be pretty easy to do
 some cgi-style replacement, e.g.
 
 TESTS = MP_TASKS_PER_NODE=4%20MP_PROCS=4%20poe%20./tst_parallel
 
 Pretty ugly and error-prone, of course, but it would be more or
 less backward compatible, and better than nothing.

Ouch.  If you admit to the hack of using environment variables, then do
this:

  env MP_TASKS_PER_NODE=4 MP_PROCS=4 make -e check

Report make/Makefile.am combinations where this fails.

Regards,
Ralf




Re: make distcheck fails for simple Makefile.am

2005-06-20 Thread Roger Leigh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ralf Wildenhues [EMAIL PROTECTED] writes:

 * Roger Leigh wrote on Sat, Jun 18, 2005 at 12:47:08PM CEST:
 
 In a simple Makefile.am:
 
 pamdir = /etc/pam.d
 pam_DATA = schroot
 EXTRA_DIST = $(pam_DATA)
 
 make distcheck fails:

 Make that 
   pamdir = $(prefix)/etc/pam.d

 but you really should be using sysconfdir:
   pamdir = $(sysconfdir)/pam.d

 so that both the casual user and the distribution packager can easily
 override the values: the former could do
   configure --sysconfdir=/etc   # rest goes under /usr/local
 whereas the latter does
   configure --prefix=/

In this case, it will always be /etc/pam.d.  This directory is the
location of the Linux-PAM service configuration files.  For security,
libpam won't look anywhere else.  The package has other files to
install in $(sysconfdir), so using $(sysconfdir) would be wrong
because it's likely I might want that to be some other value.

I /could/ do this, but I would likely need to override pamdir during
'make install' if it was wrong, which really defeats the point.  If it
only works when $(sysconfdir)=/etc, it's broken the rest of the time.

 So no, this is not a bug in Automake.

IMO the ability to use literal absolute paths is unconventional, but
sometimes required.  If make distcheck used $(DESTDIR) rather than
relying on the fact that *all* install paths begin with $(prefix), it
would be rather more reliable.

It's often the case that a package installs files in locations picked
up by configure.  e.g. in gimp-print the CUPS PPD files get installed
in `cups-config --datadir`, and the drivers in `cups-config
- --serverbin`/filter.  'make distcheck' has never worked because of
this.

In both of these cases, the location is dictated by packages already
installed on the system.  That location is completely independent of
$(prefix).

In summary:
- - any location that does not start with $(prefix) will break distcheck
- - this could be fixed by using $(DESTDIR)


- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/

iD8DBQFCtogsVcFcaSW/uEgRAiKvAJ0ZGJTRKaR8jbdtSkmMQOgDLon4ggCghaWB
H+2hTK+ctTD8HLujdPbKKzc=
=KW8k
-END PGP SIGNATURE-




Re: make distcheck fails for simple Makefile.am

2005-06-20 Thread Ralf Wildenhues
Hi Roger,

* Roger Leigh wrote on Mon, Jun 20, 2005 at 11:11:10AM CEST:
 Ralf Wildenhues [EMAIL PROTECTED] writes:
  * Roger Leigh wrote on Sat, Jun 18, 2005 at 12:47:08PM CEST:
  
  pamdir = /etc/pam.d
  pam_DATA = schroot
  EXTRA_DIST = $(pam_DATA)
  
  make distcheck fails:
 
  Make that 
pamdir = $(prefix)/etc/pam.d
 
  but you really should be using sysconfdir:
pamdir = $(sysconfdir)/pam.d

 In this case, it will always be /etc/pam.d.  This directory is the
 location of the Linux-PAM service configuration files.  For security,
 libpam won't look anywhere else.  The package has other files to
 install in $(sysconfdir), so using $(sysconfdir) would be wrong
 because it's likely I might want that to be some other value.

That strikes me as inconsistent (for general packages).  In any case, it
prevents multiple installations of the same package under different
prefixes.

 I /could/ do this, but I would likely need to override pamdir during
 'make install' if it was wrong, which really defeats the point.  If it
 only works when $(sysconfdir)=/etc, it's broken the rest of the time.

Make configure set sysconfdir to /etc unless overridden?  (That won't
solve the distcheck problem alone.)

  So no, this is not a bug in Automake.
 
 IMO the ability to use literal absolute paths is unconventional, but
 sometimes required.  If make distcheck used $(DESTDIR) rather than
 relying on the fact that *all* install paths begin with $(prefix), it
 would be rather more reliable.

Well, distcheck is meant for general purpose checking.  One item is
that packages should be installable in parallel.  Another one is that
packages should be usable by the powerless user (i.e., one without root
rights).  Both of these don't fit your package.

 It's often the case that a package installs files in locations picked
 up by configure.  e.g. in gimp-print the CUPS PPD files get installed
 in `cups-config --datadir`, and the drivers in `cups-config
 - --serverbin`/filter.  'make distcheck' has never worked because of
 this.

Hmm, DISTCHECK_CONFIGURE_FLAGS could help around this if the package
allows overriding.

 In both of these cases, the location is dictated by packages already
 installed on the system.  That location is completely independent of
 $(prefix).

OK.

 In summary:
 - - any location that does not start with $(prefix) will break distcheck
 - - this could be fixed by using $(DESTDIR)

Nono.  DESTDIR serves a different purpose, don't try to abuse it,
please.  It'll work with simple setups/packages only.

I agree with you that this is a limitation.  But I am still not sure
that it should be solved within Automake.  Why not have
 pamdir=/etc/pam.d

and set this in configure.ac but have it overridable by the user.  Then,
use DISTCHECK_CONFIGURE_FLAGS to have `make distcheck' pass?  I agree it
sounds like a hack, but then again, you _are_ violating packaging rules,
and IMVHO it's acceptable if it's difficult to get around them.

Just my opinion, though, I'd love to see arguments against it.

Regards,
Ralf