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

[Boris Kolpackov]

Markus Pawellek via users <users at build2.org> writes:

> for an application which needs to use other resources besides code,
> like a game which needs to display a background image,
> one also needs to install those resources to the directory given by 'config.install.data'.
> But the installed application also must know about the absolute path
> to the resource file to be able to load and use it.
> For me, using the 'in' module to generate code by the build system,
> which declares this path as a C++ variable, seemed to be appropriate.
> Sadly, I was not able to get this path neither from 'config.install.data' nor from 'install.data',
> because, according to the documentation,
> the 'install' variables are typically defined with starting nodes
> that are to be resolved by the 'install' module.
> Can I use this functionality to get the absolute paths for myself as well?

Yes, there was actually the same question on cpplang[1] a couple of days
ago so I am just going to copy the relevant parts:


Mark A Gibbs writes:

> Is there any documentation/guidance on how to include configuration/data
> files in an exe project? I have piles of questions, like: Where should data
> files be placed in the project? In a data/ dir in the project root? (Or
> etc/, as the canonical project structure suggests?) Or should the data/ (or
> etc/) dir be in the source directory? I assume I should include a buildfile
> in the data/ dir that either uses wildcards to mark everything in that dir
> and its subdirs as data file.. or would it be better to explicitly list the
> data files I want to install and not use wildcards? How would I mark files
> as data files to be installed [...]?
>
> What would be the best way to get the data file paths into the exe? Should I
> use something like hxx{config}: in{config}, and in config.hpp.in have lines
> like constexpr auto config_path = "$???.config.install.data$";?


Boris Kolpackov writes:

> > Where should data files be placed in the project? In a data/ dir in the
> > project root? (Or etc/, as the canonical project structure suggests?)
>
> In our own projects we use etc/ for sample configuration files. I think
> data/ is good for other data.
>
> > Or should the data/ (or etc/) dir be in the source directory?
>
> I would probably include it as a top-level directory. Also, if you only
> have one or two "data" files, then it may make sense just to put them
> into the source directory.
>
> > I assume I should include a buildfile in the data/ dir that either uses
> > wildcards to mark everything in that dir and its subdirs as data file...
> > or would it be better to explicitly list the data files I want to install
> > and not use wildcards?
>
> A buildfile in a separate data dir sounds sensible. I don't see any reason
> not to use wildcards if that feels convenient. Here is an example of etc/
> directory in one of our projects that does all of this:
>
> https://git.build2.org/cgit/brep/tree/etc
>
> > How would I mark files as data files to be installed; as far as I know
> > there’s no data{} target type, so would I use file{} and then manually
> > mark everything with install = data (or install = data/)?
>
> You can use file{} or you can define your own target type if you want to
> be fancy. Here is an example of the latter (see pem{}):
>
> https://git.build2.org/cgit/packaging/curl/ca-certificates-curl/tree/libca-certificates-curl/libca-certificates-curl/buildfile
>
> > What would be the best way to get the data file paths into the exe?
>
> If you want this to work both for installed and non-installed cases,
> then that will require some effort. We do something similar in build2:
>
> https://git.build2.org/cgit/build2/tree/libbuild2/buildfile
>
> See BUILD2_INSTALL_LIB as well as utility-installed.cxx and
> utility-uninstalled.cxx source files. In your case, you can pass
> something like $src_root/date for the non-installed case.


Mark A Gibbs writes:

> I’m still experimenting, but thus far, this seems to be the form of what I
> might go with to get installable data files. I’ve taken the ideas @boris
> suggested, and riffed on them a bit.
>
> All the data files are in a top-level directory called data, and
> data/buildfile is:
>
> define data: file
> data{*}: 
> {
>   install = data/
>   install.subdirs = true
> }
> ./: data{** -buildfile}
>
> The custom target type isn’t necessary, but I think it’s nicely
> self-documenting.
>
> In the source directory, there’s a file data.cxx.in:
>
> #include <foo/data.hxx> // until modules are widely supported!
> auto get_datadir() noexcept -> std::filesystem::path const&
> {
>	static auto const path = std::filesystem::path{"$datadir$"};
>	return path;
> }
>
> And the buildfile is:
>
> libs =
> #import libs += libhello%lib{hello}
>
> exe{foo}: {hxx ixx txx cxx}{**} $libs testscript
>
> ### start new stuff
>
> exe{foo}: cxx{data-installed}:   for_install = true
> exe{foo}: cxx{data-uninstalled}: for_install = false
>
> cxx{data-installed}: in{data}
> {
> 	datadir = $regex.replace($install.resolve($install.data), '\\', '\\\\')
> }
>
> cxx{data-uninstalled}: in{data}
> {
> 	datadir = $regex.replace($src_root/data, '\\', '\\\\')
> }
>
> ### end new stuff
>
> cxx.poptions =+ "-I$out_root" "-I$src_root"

> Now I can run the exe without installing, and it uses the data in the data/
> directory. Or I can install, and it uses the data in the installed
> location. I have only a single source file (template) for both cases, and I
> can add more stuff to the source file (like, maybe sysconfdir, or a
> mechanism to change the datadir, say, from a command-line argument, and only
> use $install.data as the default) if I want to.
>
> This is just my first take, and I may modify the plan once I get some more
> practical experience with it. Any comments? Suggestions?


Boris Kolpackov writes:

> Mostly looks good to me (the .in file is a nice idea). The only thing I
> would do is exclude the auto-generated source files from the pattern (it's
> probably doesn't matter here since they both are prerequisites, but it's
> a good discipline to maintain generally):
>
> exe{foo}: {hxx ixx txx cxx}{** -data-*installed} $libs testscript


I will reply to the second half of your email tomorrow.


[1] https://cpplang.slack.com/archives/CDJ0Z991S/p1617502674039300
    https://cpplang.slack.com/archives/CDJ0Z991S/p1617658671041200

    Note: to view you will need an account; for link to invite, see:

    https://build2.org/community.xhtml#help