[openbeosnetteam] Re: stack

  • From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
  • To: openbeosnetteam@xxxxxxxxxxxxx
  • Date: Mon, 16 Sep 2002 11:19:28 +0200 (MET DST)

On Mon, 16 Sep 2002, Philippe Houdoin wrote:

> Ingo wrote us:
> > I commented out the inclusion of src/add-ons/kernel/drivers/net/
> stack. 
> > Not only because it doesn't build, but also because the name `stack' 
> > for the net stack executable clashes with the STL header <stack>. 
> Woa, my bad: the executable name was supposed to be "net_stack_driver", 
> not simply "stack".

Yeah, that'd be better.

> > This is a bit ugly, as it makes all files that include <stack> depend 
> on the 
> > net stack being built first. I see only two solutions for this 
> problem: 
> > 1) rename the executable (e.g. `net_stack') or add grist, e.g. `<net>
> > stack', or even better `<user!net>stack' and `<kernel!net>stack' for 
> > the two flavors.
> Hum, could you explain me, eternal Jam weebie, what's "grist"?

It's a concept to make target identifiers differ that refer to files with
the same name. The problem only arises because target names shouldn't 
include a path, but only the file name. Thus files with the same name,
though being located in different directories, would be denoted by the
same target identifier. To make them differ nevertheless one can prepend a
string enclosed in `<...>' called grist. This is automatically done (by
the predefined rules) for source and object files. But this is not done
for Main targets (i.e. executables, libraries,...) causing the clash with
the stack header in our case.
> Will renaming the executable name would be enough to fix this issue?
> Like this:
> R5KernelAddon net_stack_driver : kernel drivers bin :
>       net_stack_driver.c      // net_userstack_driver.c for Userland stack 
> version...
> ;


> Bonus question: how to add support for building the kernel stack 
> version OR the userland stack version of this driver in this Jamfile? 
> Testing an env variable existence?

That's one possibility. If there are no common source files, then there's
no problem at all, and actually also no need to build them mutually
exclusively, i.e. both targets can coexist. The names for user and kernel
land stacks must differ then, or grist and target location. If there are
common source files (compiled with different flags), then an `if...
else...' approach won't work that well, nor will the other one. E.g. you
will need to call `jam clean' before switching to the other flavor. At
least unless one puts some more work into it, as done with the unit tests
where two suites are built from the same source files.

CU, Ingo

Other related posts: