Hi Mattias, JS and Robert,
My opinion is that you should not try write a complex, silly and unreadable
CMake script. Just do simple: debug packages with debug binaries, and release
packages with release binaries (and so on for any custom configuration). That
sounds far more logical and natural. And in addition this would be general: If
someone wants to build a debug package under Linux (maybe useless, but why
not?), then (s)he would have the choice of doing so. Building "package-XYZ" in
debug would always produce a corresponding "libXYZ" package with debug binaries.
So naming would be, for all platforms:
<name>-<ver>-<platform>-<arch>-<compiler>[-<dev>]-<configuration>.tgz
Windows users should then be warned to download both; as for example
"libopenscenegraph-2.8.0-win32-x86-vc80sp1-release.tgz" and
"libopenscenegraph-2.8.0-win32-x86-vc80sp1-debug.tgz" and unzip them all in the
same directory. Those who only want release binaries would skip downloading
debug ones.
Just a suggestion: is it possible to make an exception for realase, so that the
"release" name does not appear ("libopenscenegraph-2.8.0-win32-x86-vc80sp1.tgz"
for instance)? That vould insist on the fact that release are standard/default
packages. Well, that maybe too much... or not?
PS: I'm writing a
"MagicalWandThatCanTurnAtOnceAllWindowsSystemsOfTheWorldIntoLinuxDisto (tm)"
that can turn at once all Windows system of the world into a corresponding
Linux distro (how did you guess???). Unfortunately, it's in early alpha stage,
and the only thing it can do is simulate a kernel launch in a DOS box... Global
destruction of Windows systems is not for tomorrow I guess. Maybe on the next
day if we find that famous "subduction zone" Robert talked about? ;)
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Thu, 18 Dec 2008 06:49:34 +0100, Jean-Sébastien Guay
<[email protected]> a écrit:
> Hi Mattias,
>
>> I don't think the naming will be the hard part. I don't know if this
>> is hard at all. I've been resistive mostly because the currently lean
>> implementation of cpack in our source/script tree will get cluttered
>> with IF(WIN32)..ELSE...ENDIF blocks. Maintainability and readability
>> will suffer.
>
> I totally agree, there is a balance to be struck, and I totally leave it
> up to the actual people working on the CMakeLists (i.e. you ;-) ) to
> tell me what an acceptable balance is.
>
>> Am I right in that what we want (on windows) is
>> libopenscenegraph-<ver>-win32-x86-vc80sp1.tgz with release dlls
>> libopenscenegraph-<ver>-win32-x86-cv80sp1-dev.tgz with debug dlls, rel
>> and debug libs, headers
>> or is it
>> libopenscenegraph-<ver>-win32-x86-vc80sp1-release.tgz with release dlls
>> libopenscenegraph-<ver>-win32-x86-vc80sp1-debug.tgz with debug dlls
>> libopenscenegraph-<ver>-win32-x86-cv80sp1-dev-release.tgz with release
>> libs and headers
>> libopenscenegraph-<ver>-win32-x86-cv80sp1-dev-debug.tgz with debug
>> libs and headers
>>
>> I would say that the former looks better while the latter will
>> certainly be easier to get/less intrusive on our CMakeLists. I'm not
>> sure the former is possible at all given the current functionality in
>> cpack.
>
> Those are indeed the two options we have, and the first one is easier
> for the user downloading but harder (impossible?) to implement, while
> the second one is easier to implement but will require it to be clear
> what people need to download to be able to develop applications
> correctly on Windows (assuming they don't want to build OSG themselves).
>
> Have you had a look at the DJGPP zip-picker link I sent before?
>
> http://www.delorie.com/djgpp/zip-picker.html
>
> If we go with the second option, I could see something like that on the
> OSG web site. It will make a customized list of download links based on
> the answers to a few questions about what they want to do. So the second
> option is OK in my book, and I volunteer to make that web page (maybe
> not in time for 2.8 if it's released before the holidays, but shortly
> after sure).
>
> J-S
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
