Re: compile-time configuration, etc.

Stefan Karrmann <[email protected]> wrote:
> It's nice to have a documentation nearby, but if multi-line data is
> needed this format reaches its limit.

line1=`sed -n 1p < file`
line2=`sed -n 2p < file`
...

> Also common sh's read cannot read arbitrary data.

That's why I'm not using it.

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

No.  The only difference between compile-time configuration files and
files in src/ is that configuration files are intended to be edited by
the user.  The only reason for separating them is for the user's
convenience: we can easily see all the configuration parameters
without hunting through all the source files; we can compare the
configurations for two different versions of a package with diff -r,
etc.  But as far as the package's build scripts are concerned, all
these files should be treated as read-only; destroying the record of
what the user asked for is not good.  You can still do everything you
need to do in the build scripts without changing these files.  Why do
you think you need to change them?

> In ./src there are no configuration files.

In fact there are, for some packages such as daemontools and skalibs.
But I agree that it would be better if they were in a separate
directory.

> They should reside below ./package or in ./conf-compile.

I don't think package/ would be a good place for them.  Files in
package/ are not intended to be edited by the user.

> Below ./compile there may be symlinks to these files.

Indeed, compile/ can contain anything at all.  But I don't see how
such symlinks would be useful.  You already know how to access the
files by their original path, so adding another name seems gratuitous.


paul