From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-07-02 08:05:32
Jürgen Hunold wrote:
> Hi !
> I'm back from vacation and got M4 (current CVS) running again.
> I've encountered several problems with it.
Hi Jürgen! I almost started to wander where you've disappeared :-)
Welcome back, and sorry for delayed reply.
> 1. Vladimir added correct handling of .c extension. Unfortunately, I
> have an external lib which is C++m, but whose extension is .c
> Is there an easy way to get bjam to use always g++ ?
> If not, I'm just happy to use the original Makefiles and link against
> the resulting lib.
It's probably possible to allow project-root.jam to change type of .c files to
C++, though it looks like a bad solution: we need this only for a single
project, not globally.
> 2. Platform dependent dependencies.
> I'm now working on a different project which imports and later exports
> tiff Images using libtiff. Developing on Linux/Windows. So I've got to
> link against differrent libs on different platforms.
> I tried something along
> lib tiff : : <os>LINUX <name>tiff ;
> lib tiff : : <os>NT <name>$(TIFF_ROOT)/libtiff/tiff.lib ;
> but now linux os.jam chokes on unknown feature NT and vice versa.
> Is there any chance to get this working in M5 ? Or am I using the wrong
> mechanism ? It would be great if the examples/docs would contain code
> covering this.
I think you're the third person who encounters this same issue, so it should
be addressed now.
The solution proposed so far is to allow user to say:
"I'd like to use feature such-and-such, if it's already valid, it's OK,
otherwise, please make it valid".
feature.ensure-valid <os>LINUX <os>NT ;
What would you say about this approach.
> 3. STLport.
> Working great, but find a diff attached which eliminates annoying
> warning: target id '@/stlport/stlport uses deprecated syntax,
> warning: which may be removed in a future version.
> warning: reference is made from project at 'RailSys/simu'
I've made the correction. Thanks!
> I wonder if bjam could support static linking of STLport on Win32 using
> This results in linking against static lib, using system runtime.
> It uses special stlport lib with _staticx extension, build by stlport
> make target "staticx". It is quite useful, because I dont have to
> deliver STLport .dll to my customers.
So, to use stlport on windows with <link>static you'd have to
- use different name of library
- add those two defines
Yep, I think it is possible. Probably, you could try adding this feature
yourself, since I don't have static stlport readily available? The name is
computed in 'stlport-target-class.construct' and additional requirements are
> 4. Qt-Toolset
> I'm trying to add support for qt-uic "embedding" feature.
> This is used by Qt-Designer to embed *.png files in a C++ source code.
> The files are compiled with the command line
> uic -embed <unique id> <list-of .png files> - o embedded.cpp
> Thomas Witt and I have hacked some code for V1.
> Can someone drop me a hint how I can start to implement this on V2.
> And I thought I could add some more user friendliness on Win32 (library
> name, defines etc.)
What interface do you plan for the "embedding" feature. I never used it (did
not even know about it), so can't even imagine...
> 5. Speed
> I read this is coming with M6 along with test system.
> This wil be cool.
Yea, I think so too.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk