[build2] Installation Configuration Variables: Absolute Paths, Config Location, Version Tag

Markus Pawellek markus.pawellek at mailbox.org
Tue Apr 27 02:02:32 UTC 2021


I will first answer the second part.

Boris Kolpackov <boris at codesynthesis.com> wrote:

> Traditionally, config.install.etc is the directory for project's
> configuration files. In my experience, it's up to the project to
> decide whether they want to install directly into etc/ (normally
> the case if there is a single configuration file), or into a
> subdirectory (normally the case if there are multiple), or into
> both.

I agree, but still there are multiple possible configuration directories
on the system which then again depend on the 'config.install.root' variable.
According to FHS [1], using '/usr/local' as 'install.root', should provide
'/usr/local/etc' as general configuration folder,
whereas using '/usr' as 'install.root' should provide
'/etc' as general configuration folder.

> And currently this can be achieved both from inside the project:
> 
> file{myprog.conf}: install = etc/$project/
> 
> Or from the outside by whomever is installing the program:
> 
> $ b config.install.etc='data_root/etc/<project>'
> 
> So having config.install.config seems to only add a convenience
> alias. Or am I missing something?

Again, I agree and please correct me, if I am wrong.
But 'config.install.etc' is not a permanent variable 
and cannot be set in the configuration file manually.
I tried that and it did not work.
For me, this breaks the uniformity with respect to
other 'config.install.*' variables.

The main idea was to add 'config.install.etc'
and 'install.etc' as variables with the same semantics
as other 'config.install.*' and 'install.*' variables
and the behavior described above.
The 'config.install.config' and 'install.config' were,
indeed, only convenience aliases.

> > Additionally, if different versions of a project are allowed
> > and need different configurations and/or resource files,
> > the tag '<version>' would come in handy
> > when defining the directories of the installation,
> > like in the following.
> > 
> > config.install.data   = share/<private>/<project>/<version>
> > config.install.config = etc/<private>/<project>/<version>
> 
> Yes, I think that's a good idea. I've implemented it and it will
> be available with the tomorrow's restage.

Wow. That was fast.
Only one question:
Is it then still possible to call an installed application?
Or do we have to create a symlink to a specific version manually?

[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html



More information about the users mailing list