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

On Mon, 2001-10-29 at 22:50, hno@marasystems.com wrote:
> 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.

There is a patch to add in the quotes that we identified for sun
support. I don't know what the automake team will do with that though.
Do you want to try 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.

What I'd like is to make error_directory point to the common root of all
the error directories, and have a separate language variable for
determining which language to use. This is a precursor to examining any
http/1.1 language hints and using those to determine which language to
return. (At which point the config file entry becomes a list of
permitted languages, with the first one used when non is selected by the
client)
 
> > 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)

In other words, the extension is overall a "good thing"?
 
> > 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...

I agree. IMO there's quite a bit of tidy up that can be done to
configure.in, but I don't know the history of why stuff is in there, so
I haven't been speaking up. I see no reason to copy the cached directory
structure - cached hasn't been around for some time now :}.

Rob
Received on Mon Oct 29 2001 - 04:32:46 MST