Re: compile-time configuration, etc.

Paul Jarc (Thu, Apr 17, 2003 at 03:47:26PM -0400):
> "clemens fischer" <[email protected]> wrote:
> > [email protected] (Paul Jarc):
> >  <URL:http://cr.yp.to/slashpackage/management.html>:

> >> What problem is being solved here?  If someone wants to use a
> >> different "cat", a solution is already available: they can set PATH
> >> appropriately. [...]
> >
> > ah, but this means a possible change of semantics depending on $PATH
> > if different programs having the same name are mentioned in $PATH!
> > as this setting is what many users change using "borrowed" knowledge,
> > not anticipating irregular behaviour, it makes sense to either
> > require different programs to have different names or _not_ depending
> > on search order.
> 
> My point remains that almost all the time, users want to use the first
> program found in $PATH, and they should not be forced to do extra work
> in that case.  Problems caused by different versions of the same
> command are comparatively much rarer.  Solving the special-case
> problem should not impact the already-working common case.

You are right. The common situation should work without user
interaction. At least for the initial call which may remember
parts of its environment for following calls. If these information
is wrong manual work is necessary - either changeing PATH or removing
remembered information or providing some ./conf-compile/name-* files.
By remembering the necessary parts of the initial call, subsequent
calls are indepentent from the calling environment as far as possible.

In date/nstrtools it is necessary to know where boost/regex
is installed. Thus, the installer must provide this information.

> package/compile could *allow* (not require) the user to specify
> absolute paths for certain commands in the compile-time configuration,
> and use normal $PATH lookups for commands which did not have absolute
> paths given.  That would still be overkill, I think, but at least it
> would not bother the user with unnecessary work.  E.g.,
> package/compile might start like this:
> 
> #!/bin/sh -e
> cat=`sed q < conf-compile/path-cat`
> cp=` sed q < conf-compile/path-cp`
> mv=` sed q < conf-compile/path-mv`
> ln=` sed q < conf-compile/path-ln`
> ...
> "$mv" -f source-file dest-file
> "$ln" -s target link
> etc.
> 
> The conf-compile/path-* files would look like this, as distributed:
> ---- 8< ----
> cat
> 
> The first line of this file names the "cat" command to be used by
> package/compile.  You can change it to specify an absolute path if you
> don't want to use the first "cat" found in $PATH.
> ---- 8< ----

It's nice to have a documentation nearby, but if multi-line data is
needed this format reaches its limit. Also common sh's read cannot
read arbitrary data. Thus, cat is needed and even then no data in a
shell can contain NUL (=chr(0)).

> > i feel comfortable with editing preconf/conf-*, but stefan needs
> > several files in his conf-compile, so people might get used to looking
> > through preconf/conf-*/*.  or maybe conf-*/*.

I think, I need some of
./conf-compile/{cmd-cat,name-cat,name-ln,name-cc,name-as} etc.
Below ./compile I can put the symlinks which are needed for building the
package.

> Eh?  I don't think anyone's advocating multiple levels of directories
> or using "conf" more than once in the path.

Yes.

> There will be a single directory devoted to compile-time
> configuration.  It will contain nothing but regular files.  Each file
> will be used to control one configuration parameter, and will
> initially contain the default choice, with a short bit of
> documentation, like the example above.  The build process will not
> modify any of these files (or any distributed files, for that matter;
> only newly created files will be written to).  (I'm not saying all
> this should be mandated, but it is the best way to do compile-time
> configuration.)

If package foo should not change data in compile-conf then even the
defaults in ./conf-compile must NOT belong to the tar-ball. The defaults
may reside in ./package/defaults.

> The question is: what should be the name of this directory?  For the
> sake of uniformity, I'm willing to use "conf-compile", like Stefan
> does, if others will voice their agreement.  (Again, I don't think we
> need to mandate one name, but uniformity would be helpful.)

In /package is only agreement about the name hierachy. Almost everything
else is a matter of each developer. More unitomity would really help. At
least for /package-managers.

clemens fischer (Thu, Apr 17, 2003 at 11:15:43PM +0200):
> [email protected] (Paul Jarc):
> 
> > The question is: what should be the name of this directory?  For the
> > sake of uniformity, I'm willing to use "conf-compile", like Stefan
> > does, if others will voice their agreement.  (Again, I don't think
> > we need to mandate one name, but uniformity would be helpful.)
> 
> well, unless stefan brings forth a good argument for directories, i'd
> like to stick with `preconf' containing flat files.  i like this more
> than ./src/conf-* or src/sys/conf-*.  all this has confused me, i now
> see that stefan could have had preconf/conf-* or conf-compile/conf-*,
> so i started wondering what this was all about.

In ./src there are no configuration files. They should reside below
./package or in ./conf-compile. Below ./compile there may be symlinks to
these files.

Sincerly,
-- 
Stefan