I' ve done some work on CMake and OSG:
the approach for OpenThreads and Producer has been to build them in the
same build for OSG settin output dll in the same dir,
WITHOUT installation.
I configure also .bat or .sh script to set up the environment on the fly
, for example to run examples, mimicking the mew windows binary
installation structure.
I' ve arranged an external build tree that mimick the structure of OSG,
OP an OT
there is also an "assembly" cmake project that get all the stuff from
the OSG cvs repositories and then set up a target.
for this assembly, cvs.exe, tar, gzip and similar stuff are required,
they are usually available under Linux but not under windows,
so I had to collect them... any suggestion for a "windows developer
pack?" cygwin? msys? .. the cvs.exe I found does not work
well with TortoiseCvs.
I shuld be able to assemble instruction to use and download my stuff for
Linux and Windows VisualStudio.
I' ve tried to build under mingw without success
E. Wing wrote:
But that's OSG. Says nothing about OpenThreads and Producer. I'm
saying, write a CMake script that installs OpenThreads and Producer in a
way they're expected to be installed. There's really no value in
CMakeifying a build that the library maintainers themselves aren't going
to support. All your OSG users actually want is the convenience of a
one-step approach. A toplevel script that installs needed dependencies,
then builds OSG based on the available dependencies, would do the job.
So now you need only worry about CMakeifying OSG.
Cheers,
Brandon Van Every
There's an unusual relationship between OpenThreads, Producer, and
OSG. OSG is the primary user of the other two projects. I actually do
not know of other projects that use these two libraries. Furthermore,
Producer is written by one of the co-authors to OSG. OpenThreads was
created by somebody else, but I believe that the OSG authors
contributed a lot to it and it's now hosted on the OSG server.
Furthermore, the existing Make build systems look very similar to the
OSG build system and respond to similar environmental variable
conventions and tricks which I believe is no accident. I also know
that I am the provider of the Xcode projects for those other projects
and they were accepted into the main distribution, but I only went
through the OSG community, not directly to the others. So we are given
a lot of latitude with respect to CMake-ifying the other projects. We
probably could punt if we wanted, but I believe the expectation has
always been that we would port all 3 build systems. I believe the only
constraint is that we have is that people still need to be able to
build OpenThreads and Producer by themselves in case there are non-OSG
projects that use them.
Thanks,
-Eric
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
