Re: Management for relative paths in global build parameters

[Daniel Herring]

Hi Markus,

This question goes somewhat out of what make provides and into how to 
configure your makefiles.

Autoconf has a fairly good story for this.  You can steal ideas without 
using the tool.  Read up on the differences between builddir and srcdir, 
current and top_, relative and abs_.  These are all preset output 
variables in Autoconf.

https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Preset-Output-Variables.html


I generally keep relative paths within a "sub project".  When going "up", 
I use [abs_]top_srcdir/path/down.  Use [abs_]top_builddir for generated 
files.  Occasionally both srcdir and builddir are required (e.g. 
"-I$srcdir -I$builddir") because files can live in both places.


It depends on how tightly coupled your subprojects are.  One of my 
projects had a documented subproject API, where the top level defines 
standard variables for use by subprojects, and subprojects fill out 
well-known-files for use by the top project.  Top and subprojects each 
have their own separate build system.  This was done to provide "drop in" 
modularity.


- Daniel


On Wed, 7 Jun 2017, SF Markus Elfring wrote:

> Hello,
>
> Software development projects can grow in the way that corresponding components
> will be stored in several subdirectories. Such a project organisation has got
> consequences on the management of some dependencies.
>
> Now I am looking for advanced support possibilities by the make software
> once more.
>
> Components in these subdirectories will usually need some information also from
> the global build system settings. A portion of the involved configuration
> variables will eventually store relative paths.
> I imagine that desired data processing for them can trigger special development
> challenges then.
> How do you prefer to achieve consistent and safe access for paths across
> the directory hierarchy?
>
> I looked at the possibility to convert such data into absolute paths (by the
> function “abspath” for example).
> But make variables do not directly support higher level data structures for the
> transformation of passed build parameters in the way I would find convenient.
>
> How portable can extensions become for the provided function library?
>
> Regards,
> Markus
>
> _______________________________________________
> Bug-make mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-make