help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Robert P. J. Day
Subject: proper (stylish) way for Makefile to determine top of source tree?
Date: Thu, 31 Oct 2019 12:29:40 -0400 (EDT)
User-agent: Alpine 2.21 (LFD 202 2017-01-01)

  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 via email to

[Prev in Thread] Current Thread [Next in Thread]