Re: compile-time configuration, etc.

"clemens fischer" <[email protected]> wrote:
> [email protected] (Paul Jarc):
>> <URL:http://cr.yp.to/slashpackage/manamgement.html>:
>  <URL:http://cr.yp.to/slashpackage/management.html>:

Oops, right.

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

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

> 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-*/*.

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

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

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


paul