[openbeosnetteam] Re: One small step for net team, but... butone small step forward?

On Wed, 13 Nov 2002, Philippe Houdoin wrote:

> Quoting Axel Dörfler:

> > >   Unfortunnatly, currently:
> > >   - I couldn't manage to (re)create the symlink at build time
> > >   *before* running the "Addon" rule on them.
> > >   Please, Jamfile guru(s), help me! :-)
> > >   - network modules code are not yet buildable as userland add-ons.
> >
> > What exactly are you trying to do? I mean why do you need the symbolic
> > links?
> > What's the plan?
>
> I really don't want to duplicate code of each network module
> in another place in the CVS tree simply to be able to build it
> as userland add-on instead of kernel add-on.
>
> But, as most of Jam rules use the Jamfile relative location to
> create both objects/... and distro/... trees, I can't put
> the userland build in the same Jamfile than kernelland build.
> More specificly, I did try to change the 
> /current/src/add-ons/kernel/network/core/Jamfile (for example) to build as 
> userland add-on
> instead of kernel add-ons like today that way :
>
> if $(NET_SERVER) {
>   Addon core :
>      core.c
>      ...
>    : root ;
>
> } else {
>   R5KernelAddon core : ...
> }
>
> But, as the SubDir directive at top is the same, the *.o files where
> generated in the same place, which is bad!

That's right, though not inevitable. The unit tests for instance are
compiled twice -- for R5 and for OBOS. It is a bit tricky and requires
some lower level rules to be used though. That's why I offered my hand a
while ago, I guess. :-P

> So, the plan is:
> - create a specific directory for each userland network add-ons under
>   src/tests/add-ons/net_server/core, etc
> - write a Jamfile to build the module as userland add-on
> - NO DUPLICATED code, but instead symlink to the source code files
>   in the corresponding src/add-ons/kernel/network/core/ & co.
>   Obvioulsy, I can symlink manually (and locally), but CVS being what
>   he's, I want to do this a build time.
>
> That way:
> - garuanted shared code
> - different build settings

As written in my previous mail, the symlinks are actually not needed. In
fact I even like this solution better than to mess around with low level
rules. For the unit tests it was no option, but as only one directory is
concerned in this case (not several trees), it is much simpler this way.

> I've at home something starting to works that way, except that I failed
> to (re)generate symlinks to shared source code *before* building each
> network modules as userland add-on. The symlinks are created
> *after* all rules applied. Okay, build them running jam two times is NOT
> an option here!
> :-)

Sounds good. Just try the SEARCH_SOURCE solution and drop me a mail, when
you encounter problems. I'm just back from vacation and may not have much
time within the next couple of days, but for answering mails it will be
enough. :-)

CU, Ingo

Other related posts: