Re: compile-time configuration, etc.

> stefan:

[email protected] (Paul Jarc):

> If package/sharing is missing, it can probably be considered
> equivalent to an empty file (although the web page does not say that
> explicitly); having an empty file is equivalent to specifying that
> all files are only "host"-sharable.  So this may be wasteful of
> space, but is not really harmful.

Location: http://cr.yp.to/slashpackage/sharability.html:

  * host for files that might be host-specific. This is the same as
    leaving the line out of package/sharing.

my conclusion for an empty or missing ./sharing file is the same as
yours:  host-only sharing.

>> Where should the commands copied or symlinked to?
>
> <URL:http://cr.yp.to/slashpackage/manamgement.html>:
  <URL:http://cr.yp.to/slashpackage/management.html>:

>> Later runs of 'sh package/compile' only relies on information in
>> its own directory tree. (Well, this is my plan - now gcc etc. are
>> still needed to be in the PATH.)
>
> What problem is being solved here?  If someone wants to use a
> different "cat", a solution is already available: they can set PATH
> appropriately.  If necessary, they can create a new directory
> containing symlinks to particular commands, and put that directory
> first in PATH.  But in the *vast* majority of cases, PATH will
> already be correct; the user should not be forced to do extra work
> in the common case.

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.

>> preconf/. is a pretty short name, but 'preconf' does not say that
>> its contents must be provided before _compilation_.
>
> True.  I'm willing to change mine to conf-compile, but I'd like to
> hear more widespread agreement first; I don't want to have to change
> again later.

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

  clemens