[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