"lib" prefix for cross-compiled library in cygwin environment

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

"lib" prefix for cross-compiled library in cygwin environment

Mark Evans-2
The toolset I am creating for a cross-development environment on cygwin targeting HP NonStop Kernel system requires that shared libraries be generated with "lib" prefix.  Is there a way to control the decision on whether or not to generate this prefix?  This appears to be goverend by build/virtual-target.jam as follows:

rule add-prefix-and-suffix ( specified-name : type ? : property-set )
{
    local suffix = [ type.generated-target-suffix $(type) : $(property-set) ] ;
    suffix = .$(suffix) ;
   
    local prefix ;
   
    if [ type.is-derived $(type) LIB ] && [ os.on-unix ]
       && ! [ MATCH ^(lib) : $(specified-name) ]
    {
        prefix = "lib" ;
    }
   
    return $(prefix:E="")$(specified-name)$(suffix:E="") ;
}

Someone else ran into this problem and ended up having to change the rule above.  (http://archives.free.net.ph/message/20060102.130852.3389a353.en.html)

I'd rather not have to go that route.

Thanks!
Mark

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: "lib" prefix for cross-compiled library in cygwin environment

Vladimir Prus
Hi Mark,

> The toolset I am creating for a cross-development environment on cygwin
> targeting HP NonStop Kernel system requires that shared libraries be
> generated with "lib" prefix.  Is there a way to control the  decision on
> whether or not to generate this prefix?  This appears  to be goverend by
> build/virtual-target.jam as follows:
....

>       if [ type.is-derived $(type) LIB ] && [ os.on-unix ]
>          && ! [ MATCH ^(lib) : $(specified-name) ]
>       {
>           prefix = "lib" ;
>       }
>
>       return $(prefix:E="")$(specified-name)$(suffix:E="") ;
>   }
>
>   Someone else ran into this problem and ended up having to change the
> rule above.  
> (http://archives.free.net.ph/message/20060102.130852.3389a353.en.html)
>
>   I'd rather not have to go that route.

I'm afraid that's the only option possible with the current codebase. The code
above is indeed hardcoded because when it was written "lib" on Unix was the
only know usecase. Would you mind filing this as enhancement request in the
issue tracker:

   http://zigzag.cs.msu.su/boost.build

Thanks,
Volodya

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: "lib" prefix for cross-compiled library in cygwin environment

Mark Evans-2
Will write enhancement request...thanks for the info.

Mark

Vladimir Prus <[hidden email]> wrote:
Hi Mark,

> The toolset I am creating for a cross-development environment on cygwin
> targeting HP NonStop Kernel system requires that shared libraries be
> generated with "lib" prefix. Is there a way to control the decision on
> whether or not to generate this prefix? This appears to be goverend by
> build/virtual-target.jam as follows:
....

> if [ type.is-derived $(type) LIB ] && [ os.on-unix ]
> && ! [ MATCH ^(lib) : $(specified-name) ]
> {
> prefix = "lib" ;
> }
>
> return $(prefix:E="")$(specified-name)$(suffix:E="") ;
> }
>
> Someone else ran into this problem and en! ded up having to change the
> rule above.
> (http://archives.free.net.ph/message/20060102.130852.3389a353.en.html)
>
> I'd rather not have to go that route.

I'm afraid that's the only option possible with the current codebase. The code
above is indeed hardcoded because when it was written "lib" on Unix was the
only know usecase. Would you mind filing this as enhancement request in the
issue tracker:

http://zigzag.cs.msu.su/boost.build

Thanks,
Volodya

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: "lib" prefix for cross-compiled library in cygwin environment

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

For grins I took a stab at implementing a set of rules for target filename prefix provisioning that started out as almost carbon copies of the suffix provisioning rules in build/type.jam.  Then I factored out the common code in both sets of (prefix/suffix) rules to avoid copy/paste bloat. 

I changed build/virtual-target.jam to the following:

rule add-prefix-and-suffix ( specified-name : type ? : property-set )
{
    local suffix = [ type.generated-target-suffix $(type) : $(property-set) ] ;
    suffix = .$(suffix) ;
   
    local prefix = [ type.generated-target-prefix $(type) : $(property-set) ] ;
   
    if [ type.is-derived $(type) LIB ] && [ os.on-unix ]
    {
        prefix = "lib" ;
    }
    if [ MATCH ^($(prefix)! ) : $(specified-name) ]
    {
        prefix = "" ;
    }
    return $(prefix:E="")$(specified-name)$(suffix:E="") ;
}

I would like to submit what I've done for consideration.  I'm not up to speed with cvs or boost submission procedures (yet).  Can I just send the updated files for y'all to diff against the current code base and inspect?

Regards,
Mark


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: "lib" prefix for cross-compiled library in cygwin environment

Mark Evans-2
In reply to this post by Vladimir Prus
Proposed implementation for the requested feature are attached to ticket #33 (mods to build/type.jam and build/virtual-target.jam).   See https://zigzag.cs.msu.su/boost.build/ticket/33

Added a rule type.set-generated-target-prefix that follows the pattern of type.set-generated-target-suffix.

Criticism is welcome from more experienced bb2 developers.  Not sure what documentation would have to be touched in order to adopt this.

Cheers,
Mark

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: "lib" prefix for cross-compiled library in cygwin environment

Vladimir Prus
On Monday 06 February 2006 18:17, Mark Evans wrote:
> Proposed implementation for the requested feature are attached to ticket
> #33 (mods to build/type.jam and build/virtual-target.jam).   See
> https://zigzag.cs.msu.su/boost.build/ticket/33
>
> Added a rule type.set-generated-target-prefix that follows the pattern of
> type.set-generated-target-suffix.

Thanks! I'll take a look at your proposed changes tomorrow in the morning.

Thanks,
Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: "lib" prefix for cross-compiled library in cygwin environment

Vladimir Prus
In reply to this post by Mark Evans-2
On Monday 06 February 2006 18:17, Mark Evans wrote:
> Proposed implementation for the requested feature are attached to ticket
> #33 (mods to build/type.jam and build/virtual-target.jam).   See
> https://zigzag.cs.msu.su/boost.build/ticket/33
>
> Added a rule type.set-generated-target-prefix that follows the pattern of
> type.set-generated-target-suffix.
>
> Criticism is welcome from more experienced bb2 developers.  Not sure what
> documentation would have to be touched in order to adopt this.

Hi Mark,
I'm sorry that I could not review that patch when promised, but here the
review goes.

Overall, the patch is in the right direction, however there are some glitches.

The 'generated-target-ps' rule has a 'ps' argument can supposed can be either
'prefix', or 'suffix'. However, the rule makes unconditional call to
'generatated-target-prefix-real'. In fact, I don't see 'ps' argument used
anywhere except for 'key' computation.

Whenever you see "some-rule" and "some-rule-real" combination in V2, the
second is the rule that does all the work, and the first adds caching on top
of the second. Because of that, 'generated-target-ps' should call
'generated-target-ps-real', forwaring the 'ps' argument.

The parameter to 'generated-target-ps-real' rule is called 'psn' in your
patch, but the rule does not use such argument -- it uses 'ps'. Such errors
sometimes go undetected due to dynamic scoping in bjam, but it's still an
error.

There's no need to have 'generated-target-prefix-real' rule at all, or
'generated-target-suffix-real'.  Say, I want to know target suffix. Then the
sequence of calls will be

   1. generated-target-suffix
   2. generated-target-ps
   3. (unless already cached) generated-target-ps-real

I see your comment that 'generated-target-suffix-real' is now unused, but if
you modify 'generated-target-ps' to call 'generated-target-ps-real', instead
of 'generated-target-prefix-real', the 'generated-target-prefix-real' will be
unused as well. Essentially, you'll inline that rule in the only caller.

After that, both 'generated-target-prefix-real' and
'generated-target-suffix-real' can be removed.

I'm looking forward to updated patch!

Concerning the patch format: if you have CVS checkout it's preferred if
patches are submitted as output of "cvs diff -u" command, as documented in
the hacking.txt file. Amount the primary advantages is that your changes can
be more conveniently merged with the independent changes made by others.

If you have techical issues with using CVS, let me know.

Thanks,
Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: "lib" prefix for cross-compiled library in cygwin environment

Mark Evans-2
Wow!  Thanks for the feedback.  Good catches.

I'll work on getting set up with CVS and RTFM the hacking guide.

Regards,
Mark

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: "lib" prefix for cross-compiled library in cygwin environment

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

Sorry for delay - I seem to have wincvs firewall issues at work so have to do this from home.

Hopefully this will pass scrutiny.  I tested with my fledgling toolset.  When I have some slack time I'll take a stab at creating a formal regression test case unless you beat me to the punch.

See the "hack" comment in virtual-targets.jam - Can the unix handling for "lib" prefix be removed and replaced with a call to the new type.set-generated-target-prefix in the unix toolkit?  (Unix derived toolkits might not like this so I'm not sure about it.)

Regards,
Mark


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

tmp.log (2K) Download Attachment
virtual-target.jam.diff (1K) Download Attachment
type.jam.diff (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: "lib" prefix for cross-compiled library in cygwin environment

Vladimir Prus
Hi Mark,
> Hi Vladimir,
>
>   Sorry for delay - I seem to have wincvs firewall issues at work so have
> to do this from home.
>
>  Hopefully this will pass scrutiny.  I tested with my  fledgling toolset.

This version of patch is good! I've did just one mechanical changes, moving
the new 'prefix' rules near the point where 'suffix' rules are defined to
keep related functionality closer in the code.

Otherwise, everything's OK. Can you update from CVS, and if everything works
fine for you, close

    https://zigzag.cs.msu.su/boost.build/ticket/33

as fixed?

> When I have some slack time I'll take a stab  at creating a formal
> regression test case unless you beat me to the  punch.
>
>  See the "hack" comment in virtual-targets.jam - Can  the unix handling for
> "lib" prefix be removed and replaced with a call  to the new
> type.set-generated-target-prefix in the unix toolkit?   (Unix derived
> toolkits might not like this so I'm not sure about it.)

As you've already noticed, this requires

    https://zigzag.cs.msu.su/boost.build/ticket/53

to be fixed first. I'll take a look at it one day.

- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build