> 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. Pedro.
