late binding with tools based on property settings

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

late binding with tools based on property settings

Mark Evans-2
First of all, I'd like to extend my gratitude and admiration to the creators of this cool toolset.  I'm sold on the concept.

Now as I said in an earlier email I'm in the process of defining a new toolset for HP NonStop (think Tandem) compilers.  I'm wresting with the following problem:

The choice of linker tool (ld, nld, eld) for a given program or library depends on target architecture variant and an attribute (pic=yes|no) that can vary within the source tree.  My toolset "nsk" init rule, thus, cannot fix the linker program for the entire source tree.  I can employ a perl script that looks through the flags and then invokes the appropriate linker.  But how would you experts tackle this problem with bjam rules?  Is there an example in the tools directory or elsewhere that illustrates a good pattern for this?

I would search the bjam archives but there doesn't seem to be a search fu! nction at the website.  Is there a way to get a tar file of all the past discussions?

Regards,
Mark

_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: late binding with tools based on property settings

Vladimir Prus
On Thursday 26 January 2006 15:36, Mark Evans wrote:

> First of all, I'd like to extend my gratitude and  admiration to the
> creators of this cool toolset.  I'm sold on the  concept.
>
>   Now as I said in an earlier email I'm in the process of defining a new
> toolset for HP NonStop (think Tandem) compilers.  I'm wresting  with the
> following problem:
>
>   The choice of linker tool (ld, nld, eld) for a given program or library
> depends on target architecture variant and an attribute (pic=yes|no)  that
> can vary within the source tree.  My toolset "nsk" init rule,  thus, cannot
> fix the linker program for the entire source tree.  I  can employ a perl
> script that looks through the flags and then invokes  the appropriate
> linker.  But how would you experts tackle this  problem with bjam rules?
> Is there an example in the tools  directory or elsewhere that illustrates a
> good pattern for this?

I'd take the simple approach:

rule init
{
        .ld = your-detection-code-for-ld-binary-location ;
    .nld = your-detection-code-for-nld-binary-location ;
}

rule compile ( targets * : sources * : properties * )
{
        if <use-nld>true in $(properties)
        {
                TOOL on $(targets) = $(.nld) ;
        }
        else
        {
                TOOL on $(targets) = $(.ld) ;
        }
}

action compile
{
        $(TOOL) -o $(<) $(>)
}


>   I would search the bjam archives but there doesn't seem to be a search
> function at the website.  

Hmm, do we indeed have no search on lists.boost.org? Anybody has any ideas if
this can be added?

- Volodya
_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: late binding with tools based on property settings

Mark Evans-2
Thanks! 

I'm sure it will all make sense after it sinks through my dense skull.

Regards,
Mark

Vladimir Prus <[hidden email]> wrote:
On Thursday 26 January 2006 15:36, Mark Evans wrote:

> First of all, I'd like to extend my gratitude and admiration to the
> creators of this cool toolset. I'm sold on the concept.
>
> Now as I said in an earlier email I'm in the process of defining a new
> toolset for HP NonStop (think Tandem) compilers. I'm wresting with the
> following problem:
>
> The choice of linker tool (ld, nld, eld) for a given program or library
> depends on target architecture variant and an attribute (pic=yes|no) that
> can vary within the source tree. My toolset "nsk" init rule, thus, cannot
> fix the link! er program for the entire source tree. I can employ a perl
> script that looks through the flags and then invokes the appropriate
> linker. But how would you experts tackle this problem with bjam rules?
> Is there an example in the tools directory or elsewhere that illustrates a
> good pattern for this?

I'd take the simple approach:

rule init
{
.ld = your-detection-code-for-ld-binary-location ;
.nld = your-detection-code-for-nld-binary-location ;
}

rule compile ( targets * : sources * : properties * )
{
if true in $(properties)
{
TOOL on $(targets) = $(.nld) ;
}
else
{
TOOL on $(targets) = $(.ld) ;
}
}

action compile
{
$(TOOL) -o $(<) $(>)
}


> I would search the bjam archives but there doesn't seem to be a search
> function at the website.

Hmm, do we indeed have no search on lists.boost.org? Anybody has any! ideas if
this can be added?

- Volodya
_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build


_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: late binding with tools based on property settings

Mark Evans-2
In reply to this post by Vladimir Prus
Vladimir,

This is going to be a dumb question - reflects me being a jam rookie.

If in my toolset init I have:

  flags hptnsr.link    .NLD     $(condition) : $(.nld) : unchecked ;
  flags hptnsr.link    .LD      $(condition) : $(.ld)  : unchecked ;

where .nld and .ld have been set to version specific filepaths, and I have the following (naive) rule/action:

rule link ( targets * : sources * : properties * )
{
  if <runtime-link>shared in $(properties)
  {
    .TOOL on $(targets) = $(.LD) ;
    .MAIN on $(targets) += $(.LDMAIN) ;
  }
  else
  {
    .TOOL on $(targets) = $(.NLD) ;
    .MAIN on $(targets) += $(.NLDMAIN) ;
  }
}

actions link bind LIBRARIES
{
  $(.TOOL) -L"$(LINKPATH)" -o "$(<)" "$(>)" "$(.MAIN) "$(LIBRARIES)" -l$(FINDLIBS-ST) -l$(FINDLIBS-SA) $(OPTIONS)
}

In the rule block, the values of $(.LD), $(.NLD), etc. are nil but not in the action block apparently.  Why is this the case?  Is there a way for the rule block to lay hands on the values?

I can rely on using module-global variable for this stuff as you suggest but then that limits me to supporting only one version of the toolset at any given time.

Thanks, anyone, for help with this conundrum.

Cheers,
Mark



Vladimir Prus <[hidden email]> wrote:
On Thursday 26 January 2006 15:36, Mark Evans wrote:

> First of all, I'd like to extend my gratitude and admiration to the
> creators of this cool toolset. I'm sold on the concept.
>
> Now as I said in an earlier email I'm in! the process of defining a new
> toolset for HP NonStop (think Tandem) compilers. I'm wresting with the
> following problem:
>
> The choice of linker tool (ld, nld, eld) for a given program or library
> depends on target architecture variant and an attribute (pic=yes|no) that
> can vary within the source tree. My toolset "nsk" init rule, thus, cannot
> fix the linker program for the entire source tree. I can employ a perl
> script that looks through the flags and then invokes the appropriate
> linker. But how would you experts tackle this problem with bjam rules?
> Is there an example in the tools directory or elsewhere that illustrates a
> good pattern for this?

I'd take the simple approach:

rule init
{
.ld = your-detection-code-for-ld-binary-location ;
.nld = your-detection-code-for-nld-binary-location ;
}

rule compile ( targets * : sources * : properties * )!
{
if true in $(properties)
{
TOOL on $(targets) = $(.nld) ;
}
else
{
TOOL on $(targets) = $(.ld) ;
}
}

action compile
{
$(TOOL) -o $(<) $(>)
}


> I would search the bjam archives but there doesn't seem to be a search
> function at the website.

Hmm, do we indeed have no search on lists.boost.org? Anybody has any ideas if
this can be added?

- Volodya
_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build


_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build