proper (stylish) way for Makefile to determine top of source tree?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

proper (stylish) way for Makefile to determine top of source tree?

Robert P. J. Day-2

  yet another style(?) question if i might ... current project source
has top-level structure:

  proj/
    Makefile
    config.include

where the top-level Makefile "include"s that config.include file next
to it. so far, so good.

  however, the project consists of several components, each of which
resides in a subdir, *also* with its component-specific Makefile and
config.include (and source, obviously):

  proj/
    kernel/
      Makefile + config.include
    rootfs/
      Makefile + config.include
    uboot/
      Makefile + config.include

  the current workflow is, to build one of the components, you first
"cd" down into that directory and run the make there, as in:

  $ cd kernel
  $ make

  now, every component, in addition to its component-specific config
stuff, also needs to include the top-level config.include for settings
common to all components, so this is the basic "please identify the
top of my source tree" problem.

  this current project uses the following to determine the top of the
project source tree:

  PROJ_ROOT:=$(shell git rev-parse --show-toplevel)

i think you see the problem here -- this technique fails utterly if
the project is not in its git repository (if, perhaps, someone has
archived it).

  my basic question is, in a project with this structure, is it
considered proper workflow to have to "cd" into a subdir to build just
the component in that subdir? i would have thought the obvious
solution is to always make from the top, as in:

  $ make -C uboot
  $ make -C kernel
  $ make -C rootfs

that way, you *always* know where you are.

  am i reasonable in suggesting that the current way using git is
really delicate and should be rewritten? thanks.

rday

Reply | Threaded
Open this post in threaded view
|

Re: proper (stylish) way for Makefile to determine top of source tree?

Tim Murphy-4
On Thu, 31 Oct 2019 at 16:36, Robert P. J. Day <[hidden email]>
wrote:

>
>   yet another style(?) question if i might ... current project source
> has top-level structure:
>
>   proj/
>     Makefile
>     config.include
>
>   my basic question is, in a project with this structure, is it
> considered proper workflow to have to "cd" into a subdir to build just
> the component in that subdir? i would have thought the obvious
> solution is to always make from the top, as in:



There are so many ways but that is quite a common approach (cd to subdir)
and -C is lets you do that more conveniently.

  $ make -C uboot
>   $ make -C kernel
>   $ make -C rootfs
>
> that way, you *always* know where you are.
>
>   am i reasonable in suggesting that the current way using git is
> really delicate and should be rewritten? thanks.
>

In general sub-components usually know where they are in the tree and
therefore how many "../" to use in an include. If your system doesn't then
it would be interesting to know why (I can imagine reasons but speculating
is not very useful).

Looking for the enclosing .git is only fragile if there really is a
use-case for building without git but that git command also seems
unnecessary unless items shift up and down levels in the tree for some
reason - a fixed reference seems adequate.

You can also use a variable like TOP_DIR or whatever you prefer and this
means that however you determine it, it doesn't have to be hardcoded
throughout the makefile and you can also set it on commandlines e.g.

make -C uboot TOP_DIR=..
or
make -C uboot TOP_DIR=$PWD

seems a little redundant.

Using a variable is more useful when locating the output - this is the
thing that can change after all. e.g. you might want all objects to be
created away from the source so that nobody is ever tempted to check them
in.  You might be building 32 and 64 bit binaries or debug and release or
various target architectures and your scheme might require that an output
tree should have a structure that reflects these variations. In this case
it's nice to write the makefiles to reference "$(OUT_DIR)/targetname" so
that you don't have to hardcode targets for every possible variation.

Regards,

Tim
Reply | Threaded
Open this post in threaded view
|

Re: proper (stylish) way for Makefile to determine top of source tree?

Jaap Fieret-2
FREE

Jaap

> Op 31 okt. 2019 om 21:22 heeft Tim Murphy <[hidden email]> het volgende geschreven:
>
> ´╗┐On Thu, 31 Oct 2019 at 16:36, Robert P. J. Day <[hidden email]>
> wrote:
>
>>
>>  yet another style(?) question if i might ... current project source
>> has top-level structure:
>>
>>  proj/
>>    Makefile
>>    config.include
>>
>>  my basic question is, in a project with this structure, is it
>> considered proper workflow to have to "cd" into a subdir to build just
>> the component in that subdir? i would have thought the obvious
>> solution is to always make from the top, as in:
>
>
>
> There are so many ways but that is quite a common approach (cd to subdir)
> and -C is lets you do that more conveniently.
>
>  $ make -C uboot
>>  $ make -C kernel
>>  $ make -C rootfs
>>
>> that way, you *always* know where you are.
>>
>>  am i reasonable in suggesting that the current way using git is
>> really delicate and should be rewritten? thanks.
>>
>
> In general sub-components usually know where they are in the tree and
> therefore how many "../" to use in an include. If your system doesn't then
> it would be interesting to know why (I can imagine reasons but speculating
> is not very useful).
>
> Looking for the enclosing .git is only fragile if there really is a
> use-case for building without git but that git command also seems
> unnecessary unless items shift up and down levels in the tree for some
> reason - a fixed reference seems adequate.
>
> You can also use a variable like TOP_DIR or whatever you prefer and this
> means that however you determine it, it doesn't have to be hardcoded
> throughout the makefile and you can also set it on commandlines e.g.
>
> make -C uboot TOP_DIR=..
> or
> make -C uboot TOP_DIR=$PWD
>
> seems a little redundant.
>
> Using a variable is more useful when locating the output - this is the
> thing that can change after all. e.g. you might want all objects to be
> created away from the source so that nobody is ever tempted to check them
> in.  You might be building 32 and 64 bit binaries or debug and release or
> various target architectures and your scheme might require that an output
> tree should have a structure that reflects these variations. In this case
> it's nice to write the makefiles to reference "$(OUT_DIR)/targetname" so
> that you don't have to hardcode targets for every possible variation.
>
> Regards,
>
> Tim