Hi,
On Fri, 2009-07-03 at 10:35 +0200, Johannes Brunen wrote:
> Hello Gerrit,
>
> "Gerrit Vo" <[email protected]> schrieb im
> Newsbeitrag news:[email protected]...
>
> >
> > hmm, fascinating I'll have a look. I thought I tested it but it might be
> > that I screwed something in between.
> >
> Be aware that I could only take a tiny glance at the result this morning. I
> will take a deeper look this afternoon local time.
I just tried it and it looks ok, at lease with osg_supportlibs on. I'll
have to check if turning them off makes a difference.
> >> It would be fine if we can use these variables also for
> >>
> >> OSG_USE_OSGSUPPORT_LIBS:BOOL=OFF
> >>
> >> in case the user provide sensible input for them.
> >
> > I have to see if there is an easy way to do this because IIRC the
> > rest of cmake is not very aware of all the windows variants. And IIRC
> > the more common LIB_VAR=debug;/libD.lib;optimized;lib.lib way of
> > finding packages does not work with custom variants (which is a real
> > pain).
> >
> Have you looked into my cmake file.
yes
> I just defined that the release libs and
> debug libs of the support libraries are found at the same location and that
> they are named equal with the additional 'D' suffix in debug case. I then
> use the cmake string replace to get a debug variant:
>
> string(REPLACE ".lib" "D.lib" ZLIB_D_LIBRARY ${ZLIB_LIBRARY})
>
> In the target_link_library command I can then distinguish both cases easily:
>
> target_link_libraries(
> png
> debug ${ZLIB_D_LIBRARY}
> optimized ${ZLIB_LIBRARY}
> )
>
> So I have only to specify the release lib, but with an additional rule to
> obey. It is just not as universal as probably expected and requested.
yes, but this works only nicely if you have control over the names. And
all the possible platforms fall into this scheme.
Which for the path which is not through USE_SUPPORTLIBS we have not.
This is also the path through which all other platforms run so I
have to take much more care what variants all the other os flavors
prefer and provide. This is much more sensitive than the USE_SUPPORTLIBS
path as this one is only there on Windows and we have control over
the names. And I really don't want to rewrite all the FindPackage
logic camke comes with because than I would have to take care
than it work for all combinations possible.
That is why I said I have to see if there is an easy way possible to
get it working without adding another variant we have to take care
off. So currently we have:
- Windows + OSGSUPPORT_LIBS
- Windows + NO OSGSUPPORT_LIBS which cmake can auto detect
which might not work for all variants right now. This
should support the standard CMAKE FindPackage mechanism.
- Rest of the systems out there with cmake auto detect
again through FindPackage.
I don't really want to add and support another variant. If possible
I hope we can fit all the needs into these three.
> >
> > For your case it might be easier we either agree on naming the libs or I
> > make naming them flexible enough so you can slip in your builds as
> > OpenSG Support libs and utilize this. Currently it just looks for a
> > specific header under ${SUPPORT_ROOT}/include and the libs under
> > ${SUPPORT_ROOT}/lib. As long as your names match it should not be
> > a problem. The only assumption I make is that glut is actually
> > freeglut when it comes through there.
> >
> yes.
ok, the only difference I see is that we include osg which should
be easily taken out (e.g. zlib.lib instead of osgzlib.lib as the
import lib).
The only real difference I see is that there might be a difference
between static libs and dlls (I can not really tell from the examples
if your libs are static or dynamic). As we build both variants in one
go we need to have different names so I would use
Release:
zlib.lib (dll import lib)
zlib.dll (the dll)
libzlib.lib (static lib)
Debug:
zlibD.lib (dll import lib)
zlibD.dll (the dll)
libzlibD.lib (static lib)
which lib OpenSG is looking for depends on OSG_USE_STATIC_SUPPORT_LIBS,
if on the mechanism looks for libxxxx.lib if off for xxx.lib.
kind regards,
gerrit
------------------------------------------------------------------------------
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
