Re: Automake VPATH, error pages install, and a parallell make race

From: <hno@dont-contact.us>
Date: Mon, 29 Oct 2001 12:50:11 +0100

Robert Collins wrote:
>
> On Sat, 2001-10-27 at 20:37, Henrik Nordstrom wrote:
> > Hmm.. thinking about the error pages issue.. this is caused by the
> > extension to search for the error pages rather than having them as
> > targets.
>
> Are you looking at the Sun Make again? I'm still not clear on the issue/

Don't think so. The Sun Make is not at all happy with how automake
(ab)uses VPATH, and the build did succeed in all aspects except that no
error pages was installed.. will try to repeat it.

> > perhaps we should install error pages as
> >
> > etc/errors/<language>/...
> >
> > and by default install all languages, but have a configure option to
> > only install selected languages.
>
> This makes sense to me. I like it.

Good. Makes us two.

Anyone against this change?

Basically:
  a) Install all error pages.
  b) Make error_directory default to the selected language
  c) Optionally add an option to restrict which languages get installed.

> > this should make the layout and use a lot more compatible with automake,
> > eleminating the need of custom extensions.
>
> The custom extensions are designed into automake. I was saving typing
> time by using them. To do what you are suggesting a 'custom extension'
> is likely still the easiest way. Changing the layout of the installed
> files is good though.

I only see a need of a automake extension if one is to selectively
install error messages to not overwrite local customization. However,
with the layout change discussed above it can also be defined that it
one wants to make custom error messages then create a custom directory
so local customizations should be less of an issue (also signalled by
the move to sharedstate, as sharedstate is mostly static data files, not
configuration data)

> Agreed, they should be in sharedstate.
>
> Want me to do these changes?

I think we also should get rid if the ${sharedstate} / ${libexecdir}
hack we have in configure.in, or at least make it consistent. This hack
is somewhat confusing when one is setting autoconf paths, as setting one
path may indirectly switch another supposedly independent path...

Regards
Henrik
Received on Mon Oct 29 2001 - 04:04:20 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:36 MST