Broken? lib bar : : <file>...

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

Broken? lib bar : : <file>...

Mark Evans-2

I ran into a problem using the <file> feature for indicating a prebuilt library file.  After building a variant of lib bar of examples/libraries/util/foo/Jamfile, I changed the Jamfile as follows just to demonstrate the problem:

#lib bar : bar.cpp ;
lib bar : : <file>bin/hptnsr3d/libbar.so ;

The indicated file is the result of a build before changing Jamfile.  With the change to Jamfile, I get the following error trace:

/cygdrive/c/mse/proj/boost-build/build/generators.jam:918: in ensure-type from module generators
error: target { bin/hptnsr3d/libbar.so. } has no type
/cygdrive/c/mse/proj/boost-build/build/generators.jam:1138: in generators.construct from module generators
/cygdrive/c/mse/proj/boost-build/build/targets.jam:1299: in construct from module object(typed-target)@44
/cygdrive/c/mse/proj/boost-build/build/targets.jam:1150: in object(typed-target)@44.generate from module object(typed-target)@44
/cygdrive/c/mse/proj/boost-build/build/targets.jam:763: in generate-really from module object(main-target)@53
/cygdrive/c/mse/proj/boost-build/build/targets.jam:736: in object(main-target)@53.generate from module object(main-target)@53
/cygdrive/c/mse/proj/boost-build/build/targets.jam:251: in object(project-target)@43.generate from module object(project-target)@43
/cygdrive/c/mse/proj/boost-build/build-system.jam:276: in load from module build-system
/cygdrive/c/mse/proj/boost-build/example/../kernel/modules.jam:261: in import from module modules
/cygdrive/c/mse/proj/boost-build/example/../kernel/bootstrap.jam:186: in boost-build from module
/cygdrive/c/mse/proj/boost-build/example/boost-build.jam:2: in module scope from module

Is this a bonified problem or cockpit error in writing the Jamfile?



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

Re: Broken? lib bar : : <file>...

Vladimir Prus
On Thursday 09 February 2006 17:30, Mark Evans wrote:

> I ran into a problem using the <file> feature for indicating a prebuilt
> library file.  After building a variant of lib bar of
> examples/libraries/util/foo/Jamfile, I changed the Jamfile as follows just
> to demonstrate the problem:
>
> #lib bar : bar.cpp ;
> lib bar : : <file>bin/hptnsr3d/libbar.so ;
>
> The indicated file is the result of a build before changing Jamfile.  With
> the change to Jamfile, I get the following error trace:
>
> /cygdrive/c/mse/proj/boost-build/build/generators.jam:918: in ensure-type
> from module generators error: target { bin/hptnsr3d/libbar.so. } has no

That's because tools/types/lib.jam does not mark '.so' as a library suffix on
NT.

But it also has nothing to make V2 *produce* .so files. Are you sure that .so
file is produced? Can you check what's the output of:

   $ bjam -f-
   ECHO $(OS) ;

is?

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

Re: Broken? lib bar : : <file>...

Mark Evans-2
$(OS) is CYGWIN but the /target/ OS is HP NonStop. 

A .so library suffix is generated by my cross-toolset for shared libs.  FWIW it registers .so as its suffix for SHARED_LIB.  The original problem was provoked by a prebuilt shared library that had no suffix at all.

Am I stuck with using <search> instead of <file> ? 

If I were to constrain all my "imported" / prebuilt libraries to have the .so suffix, would there be a way to trick bb2 into accepting such <file>s in a cross-development scenario like this?

I'm foggy on why bb2 doesn't just tag such library <file>s as <prebuilt> and be happy if the file exists.

Thanks,
Mark

Vladimir Prus <[hidden email]> wrote:

Can you check what's the output of:

$! bjam -f-
ECHO $(OS) ;

is?


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

Re: Broken? lib bar : : <file>...

Vladimir Prus
On Friday 10 February 2006 13:58, Mark Evans wrote:
> $(OS) is CYGWIN but the /target/ OS is HP NonStop.
>
>   A .so library suffix is generated by my cross-toolset for shared  libs.
> FWIW it registers .so as its suffix for SHARED_LIB.   The original problem
> was provoked by a prebuilt shared library that had  no suffix at all.
>
>   Am I stuck with using <search> instead of <file> ?

You can just add '.so' in the list of shared library suffixes, in
tools/types/lib.jam

>   If I were to constrain all my "imported" / prebuilt libraries to have
> the .so suffix, would there be a way to trick bb2 into accepting such
> <file>s in a cross-development scenario like this?

For now, modifing lib.jam seems like the only option.

>   I'm foggy on why bb2 doesn't just tag such library <file>s as <prebuilt>
> and be happy if the file exists.

And, what will Boost.Build do with such file? If it has no idea what's the
type of the file, it has no idea if it can be linked into an executable.
Well, I can change generators code so that targets with unknown type are
silently consumed and passed on to the tool (like linker), but that seems
very fragile.

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

Re: Broken? lib bar : : <file>...

Mark Evans-2
Hi Vladimir,

A lot of the jam/bb2 underpinnings is still just magic to me so please bear with me.  With

lib foo : : <name>foo <file>/somewhere/foo ;

my naive expectation is for the system to understand that /somewhere/foo is a prebuilt library file ( but which subtype of LIB is not clear because of no suffix - is that the rub?). Could the lib rule be enhanced to understand something like:?

lib foo : <name>foo <file>/somewhere/foo <type>SHARED_LIB ;

Probably a dumb question but fools rush in.  Thanks for your generous patience.

Mark

Vladimir Prus <[hidden email]> wrote:
> I'm foggy on why bb2 doesn't just tag such library s as
> and be happy if the file exists.

And, what will Boost.Build do with such file? If it has no idea what's the
type of the file, it has no idea if it can be linked into an executable.
Well, I can change generators code so that targets with unknown type are
silently consumed and passed on to the tool (like linker), but that seems
very fragile.


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

Re: Broken? lib bar : : <file>...

David Abrahams
Mark Evans <[hidden email]> writes:

> And, what will Boost.Build do with such file? If it has no idea what's the
> type of the file, it has no idea if it can be linked into an
> executable.

It could take the user's word for it.  Maybe you need a new target
type "unknown object file."

> Well, I can change generators code so that targets with unknown type are
> silently consumed and passed on to the tool (like linker), but that seems
> very fragile.

In this case the user is asserting that the file is not only an object
file, but a library file (either static or dynamic, unspecified).  I
don't think it would be too fragile to treat those specially.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

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

Re: Broken? lib bar : : <file>...

Vladimir Prus
On Sunday 12 February 2006 17:11, David Abrahams wrote:
> Mark Evans <[hidden email]> writes:
> > And, what will Boost.Build do with such file? If it has no idea what's
> > the type of the file, it has no idea if it can be linked into an
> > executable.
>
> It could take the user's word for it.  Maybe you need a new target
> type "unknown object file."

And we'd need some rules what can and cannot be done with such targets. At the
moment, all generators complain on targets with unknown type.

> > Well, I can change generators code so that targets with unknown type are
> > silently consumed and passed on to the tool (like linker), but that seems
> > very fragile.
>
> In this case the user is asserting that the file is not only an object
> file, but a library file (either static or dynamic, unspecified).  I
> don't think it would be too fragile to treat those specially.

The only problem is that msvc.link, for example, will only handle targets of
type STATIC_LIB and IMPORT_LIB, but not just LIB. So, we need to treat

   lib a : : <file>whatever.unkown-suffix ;

as STATIC_LIB.

- Volodya


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

Re: Broken? lib bar : : <file>...

David Abrahams
Vladimir Prus <[hidden email]> writes:

> On Sunday 12 February 2006 17:11, David Abrahams wrote:
>> Mark Evans <[hidden email]> writes:
>> > And, what will Boost.Build do with such file? If it has no idea what's
>> > the type of the file, it has no idea if it can be linked into an
>> > executable.
>>
>> It could take the user's word for it.  Maybe you need a new target
>> type "unknown object file."
>
> And we'd need some rules what can and cannot be done with such targets. At the
> moment, all generators complain on targets with unknown type.

Yes, but this wouldn't be an unknown type.  It would be a known type
called "unspecified object file."

>> > Well, I can change generators code so that targets with unknown type are
>> > silently consumed and passed on to the tool (like linker), but that seems
>> > very fragile.
>>
>> In this case the user is asserting that the file is not only an object
>> file, but a library file (either static or dynamic, unspecified).  I
>> don't think it would be too fragile to treat those specially.
>
> The only problem is that msvc.link, for example, will only handle targets of
> type STATIC_LIB and IMPORT_LIB, but not just LIB. So, we need to treat
>
>    lib a : : <file>whatever.unkown-suffix ;
>
> as STATIC_LIB.

I don't see why that's a problem.  msvc's linker can't tell the
difference between static and import libraries anyway.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

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

Re: Broken? lib bar : : <file>...

Belcourt, Kenneth
In reply to this post by Vladimir Prus

On Feb 13, 2006, at 2:43 AM, Vladimir Prus wrote:

> On Sunday 12 February 2006 17:11, David Abrahams wrote:
>> Mark Evans <[hidden email]> writes:
>>> And, what will Boost.Build do with such file? If it has no idea
>>> what's
>>> the type of the file, it has no idea if it can be linked into an
>>> executable.
>>
>> It could take the user's word for it.  Maybe you need a new target
>> type "unknown object file."
>
> And we'd need some rules what can and cannot be done with such
> targets. At the
> moment, all generators complain on targets with unknown type.

Why is a source *.C file an unknown type?  I get this error on several
platforms using 1.33.1?  Do I just need to use a newer version of bjam?
  The full text of the message is below.

-- Noel

[kbelco@sahp6583 votd]$ bjam
/home/kbelco/boost_1_33_1/tools/build/v2/build/generators.jam:922: in
ensure-type from module generators
error: target { Fmwk_Algorithm.C. } has no type
/home/kbelco/boost_1_33_1/tools/build/v2/build/generators.jam:1119: in
generators.construct from module generators
/home/kbelco/boost_1_33_1/tools/build/v2/build/targets.jam:1242: in
construct from module object(typed-target)@1
/home/kbelco/boost_1_33_1/tools/build/v2/build/targets.jam:1128: in
object(typed-target)@1.generate from module object(typed-target)@1
/home/kbelco/boost_1_33_1/tools/build/v2/build/targets.jam:757: in
generate-really from module object(main-target)@1
/home/kbelco/boost_1_33_1/tools/build/v2/build/targets.jam:730: in
object(main-target)@1.generate from module object(main-target)@1
/home/kbelco/boost_1_33_1/tools/build/v2/build/targets.jam:252: in
object(project-target)@4.generate from module object(project-target)@4
/home/kbelco/boost_1_33_1/tools/build/v2/build/targets.jam:252: in
object(project-target)@3.generate from module object(project-target)@3
/home/kbelco/boost_1_33_1/tools/build/v2/build-system.jam:276: in load
from module build-system
/home/kbelco/boost_1_33_1/tools/build/v2/kernel/modules.jam:259: in
import from module modules
/home/kbelco/boost_1_33_1/tools/build/v2/kernel/bootstrap.jam:153: in
boost-build from module
/home/kbelco/boost_1_33_1/tools/build/v2/boost-build.jam:2: in module
scope from module


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