Nabble - Boost - Build

Re: [BGL] read_graphviz lib compiling

2009-11-24T05:37:35Z

Jeremiah Willcock wrote:
>
> The Jamfile is in libs/graph/build/; it should work on all platforms and
> produces a library boost_graph (with platform-specific naming
> conventions). The reason that read_graphviz is in a separate source
> file is that it is not a template, while write_graphviz is templated
> over the graph type.
>

All clear, thanks Jeremiah.

Cosimo Calabrese.

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

Re: [BGL] read_graphviz lib compiling

2009-11-24T05:36:05Z

On Tue, 24 Nov 2009, Cosimo Calabrese wrote:

> Vladimir Prus wrote:
>>> I'm using MSVS 2005 and boost 1.37.
>>>
>>> I've readed in the read_graphviz documentation that if I want to use that
>>> function I must compile a lib with the source that I can found in
>>> \libs\graph\src. But I can't find any *.jam file to do it. I've founded
>>> the Unix istruction to do it, but not for MSVS.
>>
>> Just follow the usual getting started guide. E.g.
>>
>> .\bootstrap
>> .\bjam --with-graph
>>
>
> Thanks Volodya,
>
> there are 2 issues that have confused me:
> - compared to the other boost libraries like thread, date-time, ecc...,
> graph lib requires to explicitly specify it in the list of the libs of
> the project; there aren't any automatic linking of the lib;
> - the name of the lib isn't 'libbgl-viz' like specified in the doc:
>
> http://www.boost.org/doc/libs/1_31_0/libs/graph/doc/read-graphviz.html
>
> but is complying to the other boost lib names:
> - libboost_graph-vc80-mt.lib (release version);
> - libboost_graph-vc80-mt-gd.lib (debug version);
>
> I haven't found this info anywhere in boost docs, but I've resolved

The library name has been libboost_graph for a while, and the
documentation states that.

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

Re: [BGL] read_graphviz lib compiling

2009-11-24T05:33:32Z

On Mon, 23 Nov 2009, Cosimo Calabrese wrote:

> Hi to all,
>
> I'm using MSVS 2005 and boost 1.37.
>
> I've readed in the read_graphviz documentation that if I want to use that
> function I must compile a lib with the source that I can found in
> \libs\graph\src. But I can't find any *.jam file to do it. I've founded the
> Unix istruction to do it, but not for MSVS.
>
> Which are the correct compiler params to compile the lib?
> What's the name that the lib must have?
> The lib must locate in the /stage/lib directory?
> Why the read_graphviz is in a separate cpp module, and not in a hpp file like
> the write_graphviz function?

The Jamfile is in libs/graph/build/; it should work on all platforms and
produces a library boost_graph (with platform-specific naming
conventions). The reason that read_graphviz is in a separate source file
is that it is not a template, while write_graphviz is templated over the
graph type.

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

Re: [BGL] read_graphviz lib compiling

2009-11-24T04:57:00Z

Vladimir Prus wrote:

>> I'm using MSVS 2005 and boost 1.37.
>>
>> I've readed in the read_graphviz documentation that if I want to use
>> that function I must compile a lib with the source that I can found in
>> \libs\graph\src. But I can't find any *.jam file to do it. I've founded
>> the Unix istruction to do it, but not for MSVS.
>
> Just follow the usual getting started guide. E.g.
>
> .\bootstrap
> .\bjam --with-graph
>

Thanks Volodya,

there are 2 issues that have confused me:
- compared to the other boost libraries like thread, date-time, ecc...,
graph lib requires to explicitly specify it in the list of the libs of
the project; there aren't any automatic linking of the lib;
- the name of the lib isn't 'libbgl-viz' like specified in the doc:

http://www.boost.org/doc/libs/1_31_0/libs/graph/doc/read-graphviz.html

but is complying to the other boost lib names:
- libboost_graph-vc80-mt.lib (release version);
- libboost_graph-vc80-mt-gd.lib (debug version);

I haven't found this info anywhere in boost docs, but I've resolved

> The library will be in stage\lib.
>
>> Which are the correct compiler params to compile the lib?
>> What's the name that the lib must have?
>> The lib must locate in the /stage/lib directory?
>> Why the read_graphviz is in a separate cpp module, and not in a hpp file
>> like the write_graphviz function?
>
> Only Boost.Graph maintainers can give you the authoritative answer on this, but
> my guess is that parsing is more complex matter, and therefore you don't
> want to have that code compiled into every module that calls read_graphviz,
> as would be the case if that code were fully templated or inline.
>
> - 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

Re: Ref: setting compiler options on AIX

2009-11-24T04:13:44Z

On Tuesday 24 November 2009 15:01:03 Avi Bahra wrote:

> On Tuesday 24 November 2009 13:16:07 Avi Bahra wrote:
>
> > Avi Bahra wrote:
> > > I am trying to set compiler options on the AIX in a similar manner to
> gcc,
> > > but is has no effect.
> > > i.e
> > >
> > > using vacpp : : : <compileflags>-p ;
>
> > I am using the 'out of box' bjam and have not made any changes.
> >
> > For the bjam version I have:
> > #bjam -v
> > Boost.Jam Version 3.1.17. OS=AIX.
> >
> > For function init, the file vacpp.jam was located within boost at:
> > ./tools/build/v2/tools/vacpp.
> jam
> >
> > # Configure the vacpp toolset
> > rule init ( version ? : command * : options * )
> > {
> > local condition = [
> > common.check-init-parameters vacpp : version $(version) ] ;
> >
> > command = [ common.get-invocation-command vacpp : xlC
> > : $(command) : "/usr/vacpp/bin/xlC" ] ;
> >
> > common.handle-options vacpp : $(condition) : $(command) : $(options) ;
> > }
>
> >Thanks. I've fixed this problem. See:
> >
> > https://svn.boost.org/trac/boost/changeset/57887
> >
> >- Volodya
>
>
> Thanks for the fix.
>
> Currently I can not access the change set above !

That server is not the slow side; you might want to try again
a bit later.

> Please forgive my naivety, but how does one access any fixes to bjam
> Should I wait for 3.1.18 , or is this any quicker way of getting the fix ?

It looks like you're fallen in the same trap as other users. The system is
called Boost.Build, and bjam is the low-level engine. While bjam version
is somewhat important, getting new bjam won't get you any new fixes --
you also need new Boost.Build.

I recommend that you grab a nightly package of Boost.Build. It's typically
available at http://boost.org/boost-build2, and there's 24h delay.
For this specific fix, you can get a package from
http://lvk.cs.msu.su/~ghost/boost_build_nightly/ -- in about 10 mins
from now.
The timestamp.txt file inside package has the revision -- make sure it's
greater or equal to 57887.

Hope this helps,
Volodya

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

Re: Custom generator problem

2009-11-24T04:07:49Z

On Tuesday 24 November 2009 11:51:17 Johan Nilsson wrote:

> Vladimir Prus wrote:
> > On Tuesday 17 November 2009 16:20:35 Johan Nilsson wrote:
> >
> >> Hi,
> >>
> >> I've been working on a custom generator for some time now, and have
> >> it mostly working now, with one annoying problem. It appears that
> >> using the alias rule on a target generated with my generator
> >> triggers a "Duplicate name of actual target" error.
> >
> > local copy-target = [ new file-target $(target-base) : : $(project) :
> > $(copy-action) ] ;
> >
> > copied-targets += $(copy-target) ;
> >
> > Here, you create a target, and never pass it via
> > virtual-target.register. Every newly created target must be passed
> > via it.
>
> Did you try to register $(copied-targets) as well? It doesn't make any
> difference to me - still seeing the same problem in combination with alias.
> I just changed the last line of generate-targets to this (to no effect):
>
> return [ sequence.transform virtual-target.register : $(main-target)
> $(main-foo2-target) $(copy2foo2tagged-target) $(copied-targets) ] ;
>
> Actually, not having copied-targets registered has a history. In the "real"
> generator I originally registered all virtual targets, effectively the same
> as above. IIRC there was a problem with this. These are the details (caveat:
> only as I remember it, I haven't stepped through the changes in my repo):
>
> I started to get "duplicate name of actual target" at a certain point during
> the development of the generator and I found out that by removing e.g. the
> "copied-targets" from registration I managed to get rid of those. I thought
> that made sense as I believed that virtual-targets.register descended
> through the dependency graph and found those anyway as long as they were
> dependencies of the targets that I _did_ register (such as in the example
> above). Of course, registering the virtual targets should take care of that
> duplication but I figured that I'd misunderstood something in the docs or
> that there was actually a bug lurking in there somewhere.
>
> Sorry, I've got no easy way of reproducing this latest part. Still - the
> current error occurs even with the added registration of "copied-targets".

I'm sorry -- I examined the code you have provided, but did not run it.
There are two issues:

1. If you add 'copied-targets' into the virtual-target.register call at the
end, it won't work.

2. There's another such call missing.

I attach a project that seem to work for me.

For the benefit of other readers, here's a verbose explanation. A target must be passed
via register before it's used in any way. The 'copied-targets' are used in properties
of 'main-action' and so should be registered before used there. Also, main-foo2-target
is later used in sources list of copy2foo2tagged-action and should be registered
before use.

A simplified example might help. Suppose some generator is run once and constructs
those targets

1: a.c
2: a.o = gcc.compile.c{a.c}
3: a = gcc.link{a.o}

Then suppose this generator is invoked again on the same sources with about the
same properties (which can happen when alias is involved). Then, lacking any
virtual-target.register calls, it will produce:

1: a.c (note that virtual-target.from-file eliminates duplicates, so this
the same '1' as above)
2': a.o = gcc.compile.c{a.c}
3': a = gcc.link{a.o}

Here, 2' and 3' are different targets from 2 and 3, which results in the error.
If virtual-target.register is called on 2', it will return 2, and if 2 is then
use in gcc.link action, then 3' and 3 have identical action, sources and properties,
so virtual-target.register applied to 3' will return 3. Then 3 is returned and
3' and 2' are left unused.

However, if 2' is passed to gcc.link, you end up with:

3: a = gcc.link{2:a.o}
3': a = gcc.link{2':a.o}

and virtual-target.register is unable to detect that those are the same.

Now, there's a reasonable question why is your generator invoked twice. In
this case, it's somewhat of a performance bug -- the 'Bar' metatarget is
actually built with effectively the same properties, so we should be able
to completely skip the call to generators level the second time. But the
necessary magic is not working due to combination of build-project and
alias. I'll file a bug to examine this further.

Thanks,
Volodya

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

GeneratorProblem.zip (6K) Download Attachment

Ref: setting compiler options on AIX

2009-11-24T04:01:03Z

On Tuesday 24 November 2009 13:16:07 Avi Bahra wrote:

> Avi Bahra wrote:
> > I am trying to set compiler options on the AIX in a similar manner to gcc,
> > but is has no effect.
> > i.e
> >
> > using vacpp : : : <compileflags>-p ;

> I am using the 'out of box' bjam and have not made any changes.
>
> For the bjam version I have:
> #bjam -v
> Boost.Jam Version 3.1.17. OS=AIX.
>
> For function init, the file vacpp.jam was located within boost at:
> ./tools/build/v2/tools/vacpp.

jam
>
> # Configure the vacpp toolset
> rule init ( version ? : command * : options * )
> {
> local condition = [
> common.check-init-parameters vacpp : version $(version) ] ;
>
> command = [ common.get-invocation-command vacpp : xlC
> : $(command) : "/usr/vacpp/bin/xlC" ] ;
>
> common.handle-options vacpp : $(condition) : $(command) : $(options) ;
> }

>Thanks. I've fixed this problem. See:
>
> https://svn.boost.org/trac/boost/changeset/57887
>
>- Volodya

Thanks for the fix.

Currently I can not access the change set above !

Please forgive my naivety, but how does one access any fixes to bjam
Should I wait for 3.1.18 , or is this any quicker way of getting the fix ?

Best regards,
Ta,
Avi

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

Re: [BGL] read_graphviz lib compiling

2009-11-24T03:37:55Z

On Tuesday 24 November 2009 10:43:57 Cosimo Calabrese wrote:

> Hi to all,
>
> I'm using MSVS 2005 and boost 1.37.
>
> I've readed in the read_graphviz documentation that if I want to use
> that function I must compile a lib with the source that I can found in
> \libs\graph\src. But I can't find any *.jam file to do it. I've founded
> the Unix istruction to do it, but not for MSVS.

Just follow the usual getting started guide. E.g.

.\bootstrap
.\bjam --with-graph

The library will be in stage\lib.

> Which are the correct compiler params to compile the lib?
> What's the name that the lib must have?
> The lib must locate in the /stage/lib directory?
> Why the read_graphviz is in a separate cpp module, and not in a hpp file
> like the write_graphviz function?

Only Boost.Graph maintainers can give you the authoritative answer on this, but
my guess is that parsing is more complex matter, and therefore you don't
want to have that code compiled into every module that calls read_graphviz,
as would be the case if that code were fully templated or inline.

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

Re: Ref: setting compiler options on AIX

2009-11-24T03:33:51Z

> I am using the 'out of box' bjam and have not made any changes.
>
> For the bjam version I have:
> #bjam -v
> Boost.Jam Version 3.1.17. OS=AIX.
>
> For function init, the file vacpp.jam was located within boost at:
> ./tools/build/v2/tools/vacpp.jam
>
> # Configure the vacpp toolset
> rule init ( version ? : command * : options * )
> {
> local condition = [
> common.check-init-parameters vacpp : version $(version) ] ;
>
> command = [ common.get-invocation-command vacpp : xlC
> : $(command) : "/usr/vacpp/bin/xlC" ] ;
>
> common.handle-options vacpp : $(condition) : $(command) : $(options) ;
> }

Thanks. I've fixed this problem. See:

https://svn.boost.org/trac/boost/changeset/57887

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

Visual Studio always calls bjam even on built projects

2009-11-24T02:37:51Z

When I start debugging VS says "This project is out of date" even if I
just built everything. Doesn't matter if I say yes or no, debug still
works as the exe was built previously.

Makefile project with build command:
"bjam toolset=msvc --without-python -j2"

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

Ref: setting compiler options on AIX

2009-11-24T02:16:07Z

Avi Bahra wrote:
> I am trying to set compiler options on the AIX in a similar manner to gcc,
> but is has no effect.
> i.e
>
> using vacpp : : : <compileflags>-p ;
>
>
> What have i missed ?

Volodya wrote:
>What version of Boost.Build are you using and how does the function 'init'
>in vacpp.jam look?
>
>- Volodya

//================================================================

I am using the 'out of box' bjam and have not made any changes.

For the bjam version I have:
#bjam -v
Boost.Jam Version 3.1.17. OS=AIX.

For function init, the file vacpp.jam was located within boost at:
./tools/build/v2/tools/vacpp.jam

# Configure the vacpp toolset
rule init ( version ? : command * : options * )
{
    local condition = [
        common.check-init-parameters vacpp : version $(version) ] ;

    command = [ common.get-invocation-command vacpp : xlC
        : $(command) : "/usr/vacpp/bin/xlC" ] ;

    common.handle-options vacpp : $(condition) : $(command) : $(options) ;
}

Best regards,
Ta,
Avi

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

Re: Custom generator problem

2009-11-24T00:51:17Z

Vladimir Prus wrote:

> On Tuesday 17 November 2009 16:20:35 Johan Nilsson wrote:
>
>> Hi,
>>
>> I've been working on a custom generator for some time now, and have
>> it mostly working now, with one annoying problem. It appears that
>> using the alias rule on a target generated with my generator
>> triggers a "Duplicate name of actual target" error.
>
> local copy-target = [ new file-target $(target-base) : : $(project) :
> $(copy-action) ] ;
>
> copied-targets += $(copy-target) ;
>
> Here, you create a target, and never pass it via
> virtual-target.register. Every newly created target must be passed
> via it.

Did you try to register $(copied-targets) as well? It doesn't make any
difference to me - still seeing the same problem in combination with alias.
I just changed the last line of generate-targets to this (to no effect):

return [ sequence.transform virtual-target.register : $(main-target)
$(main-foo2-target) $(copy2foo2tagged-target) $(copied-targets) ] ;

Actually, not having copied-targets registered has a history. In the "real"
generator I originally registered all virtual targets, effectively the same
as above. IIRC there was a problem with this. These are the details (caveat:
only as I remember it, I haven't stepped through the changes in my repo):

I started to get "duplicate name of actual target" at a certain point during
the development of the generator and I found out that by removing e.g. the
"copied-targets" from registration I managed to get rid of those. I thought
that made sense as I believed that virtual-targets.register descended
through the dependency graph and found those anyway as long as they were
dependencies of the targets that I _did_ register (such as in the example
above). Of course, registering the virtual targets should take care of that
duplication but I figured that I'd misunderstood something in the docs or
that there was actually a bug lurking in there somewhere.

Sorry, I've got no easy way of reproducing this latest part. Still - the
current error occurs even with the added registration of "copied-targets".

Thanks / Johan

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

[BGL] read_graphviz lib compiling

2009-11-23T23:43:57Z

Hi to all,

I'm using MSVS 2005 and boost 1.37.

I've readed in the read_graphviz documentation that if I want to use that function I must compile a lib with the source that I can found in \libs\graph\src. But I can't find any *.jam file to do it. I've founded the Unix istruction to do it, but not for MSVS.

Which are the correct compiler params to compile the lib?
What's the name that the lib must have?
The lib must locate in the /stage/lib directory?
Why the read_graphviz is in a separate cpp module, and not in a hpp file like the write_graphviz function?

Thanks in advance,
Cosimo Calabrese.

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

Re: path-constant does not work inside project-config.jam

2009-11-23T23:42:00Z

Vladimir Prus wrote:

> On Friday 20 November 2009 17:49:05 Johan Nilsson wrote:
>
>> Vladimir Prus wrote:
>>> On Thursday 12 November 2009 17:14:30 Johan Nilsson wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm trying to use project-config.jam to extend BOOST_BUILD_PATH for
>>>> my entire project. However, it seems like when using path-constant
>>>> here, the path remains relative to the current working directory.
>>>
>>> Yep, it's because project-config is a weird kind of project that is
>>> not associated with a location -- mostly, to prevent putting
>>> buildable targets there. I am playing with some alternatives now.
>>
>> Ok, thanks.
>>
>> I've worked around it by specifying the root directory in an
>> enviroment variable for now, but as mentioned I'd prefer to have the
>> project as self-containing as possible.
>
> This is fixed now, see:
>
> https://svn.boost.org/trac/boost/changeset/57836
>

Just updated from trunk, and can confirm that it works for me as well.

Thanks / Johan

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

[BGL] read_graphviz lib compiling

2009-11-23T12:30:21Z

Hi to all,

I'm using MSVS 2005 and boost 1.37.

I've readed in the read_graphviz documentation that if I want to use
that function I must compile a lib with the source that I can found in
\libs\graph\src. But I can't find any *.jam file to do it. I've founded
the Unix istruction to do it, but not for MSVS.

Which are the correct compiler params to compile the lib?
What's the name that the lib must have?
The lib must locate in the /stage/lib directory?
Why the read_graphviz is in a separate cpp module, and not in a hpp file
like the write_graphviz function?

Thanks in advance,
Cosimo Calabrese.

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

Re: setting compiler options on AIX

2009-11-23T08:39:39Z

Avi Bahra wrote:

> I am trying to set compiler options on the AIX in a similar manner to gcc,
> but is has no effect.
> i.e
>
> using vacpp : : : <compileflags>-p ;
>
>
> What have i missed ?

What version of Boost.Build are you using and how does the function 'init'
in vacpp.jam look?

- Volodya

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

setting compiler options on AIX

2009-11-23T08:25:06Z

I am trying to set compiler options on the AIX in a similar manner to gcc, but is has no effect.
i.e

using vacpp : : : <compileflags>-p ;

What have i missed ?

Any help appreciated.

Best regards,
Ta,
Avi

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

[BGL] read_graphviz lib compiling

2009-11-23T07:50:33Z

Hi to all,

I'm using MSVS 2005 and boost 1.37.

I've readed in the read_graphviz documentation that if I want to use
that function I must compile a lib with the source that I can found in
\libs\graph\src. But I can't find any *.jam file to do it. I've founded
the Unix istruction to do it, but not for MSVS.

Which are the correct compiler params to compile the lib?
What's the name that the lib must have?
The lib must locate in the /stage/lib directory?
Why the read_graphviz is in a separate cpp module, and not in a hpp file
like the write_graphviz function?

Thanks in advance,
Cosimo Calabrese.

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

Re: Problem with MSVCP80D.DLL

2009-11-22T23:00:38Z

On Monday 23 November 2009 08:37:48 Derwin Dexter Sy wrote:

> I know there are a lot of threads about this, but none seem to fit my
> situation.
>
> In my case, only the Release build of my project fails with this error.
>
> The Debug build works OK.
>
>
>
> Initially I thought it had to do with my own project settings (I'm using
> MS VS2005 w/ SP1).
>
> But I managed to isolate the problem to the Boost library.
>
> I built Boost Regex using VC80.
>
> It seems odd to me that it would need MSVCP80D.DLL in a release build.
> At least, I assume it was built in release. I used the Makefile that
> came with the Boost download, with some minor changes.
>
> Is there something I can change in the Makefile to make it not need this
> DLL?

Derwin,

I am afraid I cannot comment on Makefiles. These are provided as convenience,
and not supported. If you want to get yourself a release build of boost.regex,
you should run the following commands in the root of Boost source tree:

.\bootstrap
.\bjam.exe variant=release --with-regex

and the libraries will be then found in 'stage\lib' directory.

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

Re: Using bjam in the sandbox

2009-11-22T22:58:21Z

Edward Diener wrote:

>> I agree that the error message is not exactly clear. Nor is the link
>> direct enough.
>>
>> At present I recommend you to
>>
>> - set environment variable BOOST_BUILD_PATH to <boost-root>/tools/build/v2
>> - set environment variable BOOST_ROOT to <boost-root>
>> - let me know if any sandbox library fails to work with those settings. I'll
>> fix logging shortly.
>
> I set both BOOST_BUILD_PATH and BOOST_ROOT and tried bjam in the sandbox
> logging directory. I no longer get any errors. My output is now:
>
> "warning: No toolsets are configured.
> warning: Configuring default toolset "msvc".
> warning: If the default is wrong, your build may not work correctly.
> warning: Use the "toolset=xxxxx" option to override our guess.
> warning: For more configuration options, please consult
> warning:
> http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html
>
> ...found 1 target..."
>
> I am glad it is no longer giving me errors but that last line is not
> very informative either. What target has been found ?

'all' ;-)

> Has anything been
> built ? This is the sort of thing that always bothers me about using
> bjam. I think the output needs to be informative enough to tell the user
> what has happened.

How about:

Nothing to do (no file targets found)

for the above cases, and

Nothing to do (13 file targets up-to-date)

in case of a project that actually has something to build?

>
>>
>> For future, what would you say about the following wording:
>>
>> Boost.Build could not be located.
>>
>> The Boost.Build startup module, 'bootstrap.jam', could not be found.
>> The search was performed in:
>>
>> - Directories given by the BOOST_BUILD_PATH environment variable:
>> - currently none
>> - In the directory of bjam.exe:
>> - c:/something/
>>
>> Please see <direct link to reference> for further details.
>>
>> Note that this is not a wording change only -- it depends on some behaviour
>> changes to be done first.
>
> The above is much more informative.

OK. I've added this to my todo for 1.42

>>> In particular, is there some Boost.Build documentation
>>> which explains how .bjam files are found ? I do not see this as a topic
>>> heading anywhere in the Boost.Build v2 documentation.
>>
>> Does http://tinyurl.com/ybocjzv answer your questions? (This link is outside
>> Boost, since there are some site problems, that should resolve in 24 hours)
>
> Yes, that explains it well. But should not there be docs on how .bjam
> files are found in general ? Does all finding of .bjam files follow the
> same rules as explained in that link, ie. up the file hierarchy and then
> in the directories of BOOST_BUILD_PATH ? If not, then you should explain
> how .bjam search actually works. In either case it would be welcome if
> there were a general topic in the Boost Build doc of how Boost Build
> finds .bjam files.

I think the only other context when Boost.Build is searching for .jam files
is when either 'import' or 'using' statement is found somewhere. In that case
the named module is searched for in BOOST_BUILD_PATH, only. I've added a
todo item to document this.

Thanks for feedback,
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

Problem with MSVCP80D.DLL

2009-11-22T21:37:48Z

I know there are a lot of threads about this, but none seem to fit my situation.

In my case, only the Release build of my project fails with this error.

The Debug build works OK.

Initially I thought it had to do with my own project settings (I’m using MS VS2005 w/ SP1).

But I managed to isolate the problem to the Boost library.

I built Boost Regex using VC80.

It seems odd to me that it would need MSVCP80D.DLL in a release build. At least, I assume it was built in release. I used the Makefile that came with the Boost download, with some minor changes.

Is there something I can change in the Makefile to make it not need this DLL?

Thank you.

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

Re: path-constant does not work insideproject-config.jam

2009-11-21T03:51:13Z

On Friday 20 November 2009 17:49:05 Johan Nilsson wrote:

> Vladimir Prus wrote:
> > On Thursday 12 November 2009 17:14:30 Johan Nilsson wrote:
> >
> >> Hi,
> >>
> >> I'm trying to use project-config.jam to extend BOOST_BUILD_PATH for
> >> my entire project. However, it seems like when using path-constant
> >> here, the path remains relative to the current working directory.
> >
> > Yep, it's because project-config is a weird kind of project that is
> > not associated with a location -- mostly, to prevent putting buildable
> > targets there. I am playing with some alternatives now.
>
> Ok, thanks.
>
> I've worked around it by specifying the root directory in an enviroment
> variable for now, but as mentioned I'd prefer to have the project as
> self-containing as possible.

This is fixed now, see:

https://svn.boost.org/trac/boost/changeset/57836

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

Re: Building Boost on 64-bit CentOS 5.4

2009-11-20T10:14:36Z

Interesting. I dug into the pyport.h file and found that it has a single include - pyconfig.h

This .h file is constructed by ./configure and supposed copied into the python Include/ directory. In my case, it was not copied into the correct location, and pyport.h was failing to have the properly architecture configured version of variable definitions. Specifically, LONG_BIT was defined for 32-bit by default and not 64-bit, as is my OS. Placing the file in the right location seemed to allow boost to build without any apparent errors.

Thank you for your assistance.

-Kirk

On Thu, Nov 19, 2009 at 11:35 PM, Vladimir Prus <ghost@...> wrote:

On Friday 20 November 2009 02:30:50 rkdelisle@... wrote:

> I'm trying to build boost on a 64-bit CentOS 5.4 install. I have Python
> 2.6.4 built and installed at /opt/Python_2.6.4/, and I've appended the
> user-config.jam file with:
>
> using python : 2.6 : /opt/Python_2.6.4/python : /opt/Python_2.6.4/Include :
> /opt/Python_2.6.4/Lib ;
>
> The standard system Python is 2.4.1 but the tools I'm using require 2.6, so
> I've built this version and installed it independently of the system
> version 2.4.1 to avoid any conflicts.
>
> As I'm sure you've already imagined, I get the error:
>
> LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)
>
> I see that this is a long standing bug, but I have yet to find a fix. I've
> tried various CCFLAGS, CXXFLAGS, etc. to push for a 64-bit compile or a
> 32-bit compile (-m64 or -m32).
>
> The offending file is pyport.h - is there a 64-bit friendly version that I
> don't know about?

Does this error happen if you write a test program that includes just that file,
and try to compile it by hand? If so, I suggest you raise the bug with CentOS folks.

Did you try to look at the code that emits the error? What is it checking for?

- 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

Re: Custom generator problem

2009-11-20T07:14:17Z

On Tuesday 17 November 2009 16:20:35 Johan Nilsson wrote:

> Hi,
>
> I've been working on a custom generator for some time now, and have it
> mostly working now, with one annoying problem. It appears that using the
> alias rule on a target generated with my generator triggers a "Duplicate
> name of actual target" error.

local copy-target = [ new file-target $(target-base) : : $(project) : $(copy-action) ] ;

copied-targets += $(copy-target) ;

Here, you create a target, and never pass it via virtual-target.register. Every newly created
target must be passed via it.

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

Re: Library generation GCC on Windows vs Linux

2009-11-20T06:55:49Z

How is this collision? Not too familiar with msvc dll export libs.

If I understand correctly the lib you need to link to use "hello.dll" is
called "hello.lib". The dll libs aren't put in the same directory so is
that really an issue?

g++ (GCC) 3.4.5 (mingw-vista special r3)
ln (GNU coreutils) 5.97
MinGW-5.1.4

Even if MinGW at some point looked for "libhello.lib" you'd still have
the issue of MSVC not finding "hello.lib". Surely must be a way to make
them both happy so you don't have to rename libs every time you build or
keep compiler specific settings for all static libs in the Jamfile?

Christian

Rene Rivera wrote:

> Christian Auby wrote:
>> Just noticed that with toolset=msvc the library is called
>> "libhello.lib". Most libs that comes with the MSVC compiler do not have
>> the "lib"-prefix, so I guess boost.build should have called this
>> "hello.lib"?
>>
>> Supported by this error:
>>
>> "LINK : fatal error LNK1181: cannot open input file 'hello.lib'"
>>
>> depending on "hello"-lib does not look for "libhello.lib" but
>> "hello.lib".
>>
>> Renaming it to "hello.lib" makes it link.
>>
>> I did a manual fix of this, and with the two fixes combined the
>> exe-jamfile works with both mingw and msvc without changes.
>>
>> Fix:
>>
>> type.set-generated-target-prefix STATIC_LIB : <toolset>msvc : "" ;
>
> Unfortunately that creates a collision with MSVC DLL export LIBs. And
> hence why "lib" is prefixed to the static libraries. And to be
> consistent so was mingw. But at some point the Min GCC would search for
> "libxyz.lib", among a large list of other combinations, when specifying
> -lxyz. Which version of MinGW are you using?
>
>

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

Re: path-constant does not work insideproject-config.jam

2009-11-20T06:49:05Z

Vladimir Prus wrote:

> On Thursday 12 November 2009 17:14:30 Johan Nilsson wrote:
>
>> Hi,
>>
>> I'm trying to use project-config.jam to extend BOOST_BUILD_PATH for
>> my entire project. However, it seems like when using path-constant
>> here, the path remains relative to the current working directory.
>
> Yep, it's because project-config is a weird kind of project that is
> not associated with a location -- mostly, to prevent putting buildable
> targets there. I am playing with some alternatives now.

Ok, thanks.

I've worked around it by specifying the root directory in an enviroment
variable for now, but as mentioned I'd prefer to have the project as
self-containing as possible.

/ Johan

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

Re: Library generation GCC on Windows vs Linux

2009-11-20T06:30:38Z

Christian Auby wrote:

> Just noticed that with toolset=msvc the library is called
> "libhello.lib". Most libs that comes with the MSVC compiler do not have
> the "lib"-prefix, so I guess boost.build should have called this
> "hello.lib"?
>
> Supported by this error:
>
> "LINK : fatal error LNK1181: cannot open input file 'hello.lib'"
>
> depending on "hello"-lib does not look for "libhello.lib" but "hello.lib".
>
> Renaming it to "hello.lib" makes it link.
>
> I did a manual fix of this, and with the two fixes combined the
> exe-jamfile works with both mingw and msvc without changes.
>
> Fix:
>
> type.set-generated-target-prefix STATIC_LIB : <toolset>msvc : "" ;

Unfortunately that creates a collision with MSVC DLL export LIBs. And
hence why "lib" is prefixed to the static libraries. And to be
consistent so was mingw. But at some point the Min GCC would search for
"libxyz.lib", among a large list of other combinations, when specifying
-lxyz. Which version of MinGW are you using?

--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Re: path-constant does not work inside project-config.jam

2009-11-20T06:27:06Z

On Thursday 12 November 2009 17:14:30 Johan Nilsson wrote:

> Hi,
>
> I'm trying to use project-config.jam to extend BOOST_BUILD_PATH for my
> entire project. However, it seems like when using path-constant here, the
> path remains relative to the current working directory.

Yep, it's because project-config is a weird kind of project that is
not associated with a location -- mostly, to prevent putting buildable
targets there. I am playing with some alternatives now.

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

Re: Library generation GCC on Windows vs Linux

2009-11-20T05:59:53Z

Just noticed that with toolset=msvc the library is called
"libhello.lib". Most libs that comes with the MSVC compiler do not have
the "lib"-prefix, so I guess boost.build should have called this
"hello.lib"?

Supported by this error:

"LINK : fatal error LNK1181: cannot open input file 'hello.lib'"

depending on "hello"-lib does not look for "libhello.lib" but "hello.lib".

Renaming it to "hello.lib" makes it link.

I did a manual fix of this, and with the two fixes combined the
exe-jamfile works with both mingw and msvc without changes.

Fix:

type.set-generated-target-prefix STATIC_LIB : <toolset>msvc : "" ;

Christian

Vladimir Prus wrote:

> On Friday 20 November 2009 16:12:16 Christian Auby wrote:
>
>> If I rename "libhello.lib" to "libhello.a" it does link as expected on
>> MinGW.
>
> BTW, does it really link? I though that mingw does not like the fact that
> Boost.Build does not ran 'ranlib' on static libraries...
>
> - 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

Re: Custom generator problem

2009-11-20T05:39:11Z

Ping?

Johan Nilsson wrote:

>> Hi,
>>
>> I've been working on a custom generator for some time now, and have
>> it
>> mostly working now, with one annoying problem. It appears that using
>> the
>> alias rule on a target generated with my generator triggers a
>> "Duplicate
>> name of actual target" error.
>>
>> The generator is a custom test execution generator; in the spirit of
>> the
>> built-in unit-test rule a specially named file is created if all
>> tests
>> passed, which is used as a marker to determine if the test results
>> are
>> up-to-date and ok.
>>
>> The generator basically does this:
>>
>> - Accepts a shared library, the "test library", as source (contains
>> unit
>> tests)
>> - Copies the test library to the output directory
>> - Copies all run-time dependencies (shared libs, basically) of the
>> test
>> library to the output directory before running the tests
>> - Runs the test runner, passing the name of the test library on the
>> command-line
>> - NOTE: It is not possible to simply extend PATH before running the
>> tests,
>> as is done in testing.jam.
>>
>> Optionally:
>>
>> - Generates XML output from the test runner to a file in the target
>> directory
>> - Copies the generated XML output files (tagged with <variant>) to a
>> common
>> output directory
>>
>> All this seems to work fine, even when running a multi-variant build
>> (e.g.
>> bjam debug release). But - if I alias the test target when
>> generating XML I
>> get the above error, even if only running a single-variant build.
>>
>> I've been trying to reduce the code to the simplest reproducible
>> test case, attached as a .zip archive. I'd be very grateful if
>> someone could take a
>> look at the problem as I'm pretty much stumped at this point. (This
>> is not
>> the real generator, as you can see by the file types.)
>>
>> To see the problem, unzip the archive and remove the comment before
>> the
>> alias rule in jamroot.jam. NOTE: The attached project probably only
>> works
>> under Windows, but with minor modifications it should run under *nix
>> as
>> well. The contained .dlls are just dummy text files.
>>
>> Thanks / Johan
>>
>
>
>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost-build

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

Re: Library generation GCC on Windows vs Linux

2009-11-20T05:33:19Z

Snip:

---
D:\dev\projects\test\hello>bjam -d+2 -a
gcc.compile.c++ bin\gcc-mingw-3.4.5\debug\link-static\main.o

"g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g
-I"d:\dev\bin\boost" -I"lib" -c -o "bin\gcc-mingw-3.4.5\debu
g\link-static\main.o" "main.cpp"

gcc.link bin\gcc-mingw-3.4.5\debug\link-static\app.exe

"g++" -L"d:\dev\bin\boost\stage\lib" -L"lib" -o
"bin\gcc-mingw-3.4.5\debug\link-static\app.exe" -Wl,--start-group
"bin\gcc-mingw-3.4.5\debug\link-static\main.o" -Wl,-Bstatic -lhello
-Wl,-Bdynamic -Wl,--end-group -g
---

Yes links fine. I've used MinGW + boost.build for a while now.

Christian

Vladimir Prus wrote:

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

Re: Library generation GCC on Windows vs Linux

2009-11-20T05:28:21Z

On Friday 20 November 2009 16:12:16 Christian Auby wrote:

> If I rename "libhello.lib" to "libhello.a" it does link as expected on
> MinGW.

BTW, does it really link? I though that mingw does not like the fact that
Boost.Build does not ran 'ranlib' on static libraries...

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

Re: Library generation GCC on Windows vs Linux

2009-11-20T05:27:22Z

On Friday 20 November 2009 16:12:16 Christian Auby wrote:

> If I rename "libhello.lib" to "libhello.a" it does link as expected on
> MinGW. So I think you are right in that this is a naming bug. I guess
> GCC (at least Mingw) looks for both "hello.lib" and "libhello.a" with
> -lhello. Problem is that boost.build names it somewhere inbetween.

Fixed thusly:

https://svn.boost.org/trac/boost/changeset/57816

If you run into further mingw issues, please let me know -- I hope to
make mingw a first class citizen, including linux->mingw cross, for 1.42.

- Volodya

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

Re: Library generation GCC on Windows vs Linux

2009-11-20T05:12:16Z

If I rename "libhello.lib" to "libhello.a" it does link as expected on
MinGW. So I think you are right in that this is a naming bug. I guess
GCC (at least Mingw) looks for both "hello.lib" and "libhello.a" with
-lhello. Problem is that boost.build names it somewhere inbetween.

regards,

Christian

Vladimir Prus wrote:

> On Friday 20 November 2009 15:37:47 Christian Auby wrote:
>
>> First I compile a simple lib, like this:
>>
>> lib hello : hello.cpp ;
>>
>> This creates "libhello.lib" on Mingw and "libhello.a" on Linux. However,
>> if I compile an exe-file that requires the resulting lib (not depending
>> on the actual target, I can't do this because the lib is compiled
>> somewhere else):
>>
>> lib hello ;
>>
>> exe app : hello ;
>>
>> This works on Linux since -lhello automatically looks for "libhello.a".
>> However, on Windows this looks for "hello.lib" which doesn't exist.
>> Seems to me the library generation on MinGW shouldn't add "lib" in front
>> of the resulting library name, or have I missed something?
>
> This seems like a bug -- I suspect the right solution is to use libhello.a
> on mingw, but I'll need to check how the libraries are named in the
> standard distribution.
>
> - 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

Re: Library generation GCC on Windows vs Linux

2009-11-20T04:59:28Z

On Friday 20 November 2009 15:37:47 Christian Auby wrote:

> First I compile a simple lib, like this:
>
> lib hello : hello.cpp ;
>
> This creates "libhello.lib" on Mingw and "libhello.a" on Linux. However,
> if I compile an exe-file that requires the resulting lib (not depending
> on the actual target, I can't do this because the lib is compiled
> somewhere else):
>
> lib hello ;
>
> exe app : hello ;
>
> This works on Linux since -lhello automatically looks for "libhello.a".
> However, on Windows this looks for "hello.lib" which doesn't exist.
> Seems to me the library generation on MinGW shouldn't add "lib" in front
> of the resulting library name, or have I missed something?

This seems like a bug -- I suspect the right solution is to use libhello.a
on mingw, but I'll need to check how the libraries are named in the
standard distribution.

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