Hi Pedro,
On 26.09.2012 20:05, Pedro Giffuni wrote:
From: Armin Le Grand
...
I builded a lot of other modules in this working copy with debug=t, all
worked well except svtools...
The question is how long will we be able to live with not being able to
debug in svtools on windows? Not a good situation...
I just found out that svtlls part called hatchwindowfactory *can* be
linked when adding the following:
Index: Library_hatchwindowfactory.mk
===================================================================
--- Library_hatchwindowfactory.mk (revision 1389804)
+++ Library_hatchwindowfactory.mk (working copy)
@@ -43,6 +43,7 @@
tk \
tl \
vcl \
+ stl \
$(gb_STDLIBS) \
))
@Pedro: Is this a solution? Maybe when using debug, extra stuff using
stl to verify things (remember data in a vector?) gets compiled. I do
not know how bad it is to always link against stl for
hatchwindowfactory, even without debug build. What do You think?
Ah, I see. The problem is we would be adding a dependency to stlport
*always* and in theory we are hoping to get rid of it ;-).
There is no option to do --without-stlport or to skip for debug builds
in our Windows build, right? :(
I don't really have a problem. I have been considering two alternatives
instead of getting rid of stlport:
1) There are patches to build the latest version of stlport with clang.
2) a bugzilla issue suggests apache stdcxx.
Both are very difficult to implement but it's not clear that simply removing
stlport and replacing it with more dependencies on boost is the way to
go.
In sum... yes, go ahead and add the dependency but note it carefully
in the commit log so we are able to find it if we need to know later on.
I committed that change, commented in the commit message. That
dependency is not too bad, it will be removed (has to be removed) when
we will do the STL cleanup and use only system stl. Hopefully this is
not too far in the future ;-)
Pedro.
