help-make
[Top][All Lists]
Advanced

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

how to define generic targets in an OSS-based recursive structure?


From: Robert P. J. Day
Subject: how to define generic targets in an OSS-based recursive structure?
Date: Thu, 13 Jan 2005 07:27:09 -0500 (EST)

  (first, i want to thank profusely everyone who's put up with my
occasionally inane questions as i slowly got a handle on all of this.
some day, i figure i'll even be in a position to *answer* some
questions posted here.)

  ok, here's the situation: embedded systems project, which consists
of bundling together a linux kernel, OSS stuff like busybox, PPP, and
other stuff.  so, the overall structure consists of a top-level
Makefile, and those various components in subdirectories.

  now, at the top level, i want to define (among other things) the
ubiquitous generic targets like "clean", "configure", "build",
"install" and so on.  however, because some of the parts are OSS
software, i have no control over how *those* parts are configured,
built, cleaned, etc.

  i can't just create the standard recursive make that descends into,
say, the kernel source directory, or the busybox directory, or the PPP
directory, and "make configure" there.  every single piece of OSS
software may have a different idea of what it means to "configure".

  in one case, it might be to run "make configure".  in another, it
might be to run "./configure".  in yet another, perhaps
"./autogen.sh", followed by "./configure".

  for example, in the case of the linux kernel, a basic configuration
would involve handing the configuration process a .config file, and
running something like:

  $ make mrproper
  $ cp $CONFIG_FILE .config
  $ yes '' | make oldconfig
  $ make include/linux/version.h

you get the idea.  effectively, for every piece of OSS software, i
have to define what it means to configure, build and install that
component.

  my solution so far has been, for each OSS component, to add an
intermediate layer where i define all those component-specific
targets and also support multiple configuration choices and even
software version choices.  for example, to handle the linux kernel, i
have:

  kernel/               # my overall kernel directory
    Makefile            # my definition for generic targets
    configfile.1
    configfile.2
    configfile.3
    ... more config files? ...
    linux-2.6.7/
    linux-2.6.8/
    linux-2.6.9/
    ... more kernel source trees? ...

so, to configure a linux kernel, i might just do:

  ${MAKE} \
    CONFIG_FILE=configfile.2 \
    SOURCE_TREE=linux-2.6.8 \
    -C kernel \
    configure

any my *kernel-specific* makefile takes over and knows exactly how to
continue.

  so far, this has worked all right, but rather than having all these
OSS-specific build utilities and makefile scattered all over the
directory structure, i figured i'd like to centralize it so that other
projects can take advantage of them.  but how best to do that?  i have
a number of ideas but, rather than describe them (and the one approach
i think will work the best), i just thought i'd ask if someone else
has gone through this and how they handled it.

  it seems that this is a fairly common problem, so i have to believe
lots of folks have gone through this before.

  thoughts?

rday




reply via email to

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