Hi Robert, On 12/15/08, Robert Osfield <[email protected]> wrote: > Thanks Mathias, all changes including following up change for WIn32 > ENDIF now merged and submitted to svn.
thanks > > I've ran tests and things a working well save for the in source build > when running package_source. I think we we'll probably be better > served by doing an svn export and zip then using this build_source > target. Is it easy for us to drop this target and create our own > version? I'm pondering how to do this best. My problem is that the CPack.cmake creates both the CPackSourceConfig.cmake *and* the package_source target automagically. There is the possiblity to ignore including CPack.cmake and provide all it's functionality (except generating the src target) ourselves. I don't think this is a very good solution long term so I'm trying to figure out how to trick it to hide this target. Adding our own target with svn export and tar/gzip/7zip won't be hard I think so I will have a bash at that. Mattias > > Robert. > > On Mon, Dec 15, 2008 at 11:58 AM, Mattias Helsing <[email protected]> > wrote: >> Hi all, >> >> Cpack support submission with: >> >> Better package naming. example >> openscenegraph-core-2.7.7-Linux-i386.tar.gz on my ubuntu laptop and >> openscenegraph-core.2.7.7-win32-x86-vc80.tar.gz on winxp. >> >> CMakers will not get options for selecting compression format. TGZ >> goes for all platforms (on win32 I use 7zip) >> >> The wrappers is now given the COMPONENT name >> libopenscenegraph-wrappers. Feel free to change the name. >> >> On windows with visual studio the OsgCPack script make some efforts to >> discover the compiler used but support is a bit poor so I've given >> CMake acces to OSG_CPACK_COMPILER to provide some mean to name the >> compiler. >> >> stop >> >> The platform part is taken from CMAKE_SYSTEM_NAME and for windows I >> change this to win32 or win64 based on CMAKE_CL_64. This might not be >> necessary if the arch part has that information. This information is >> taken from CMAKE_SYSTEM_PROCESSOR. I only have 32bit here so if some >> of you could uncomment line 15,16 in OsgCPack.cmake and report what >> cmake report it would be nice. I'm especially interested anything but >> win32 and linux32 >> >> Mattias >> >> On 12/15/08, Mattias Helsing <[email protected]> wrote: >>> Hi all, >>> >>> I submitted a patch on saturday but guess it bounched. Can't find it >>> in gmane. Since I have access to a windows computer I'll run some >>> windows tests before resubmitting. I'm inlining the (lengthy - sorry) >>> mail that accompanied the submission since it is very much part of the >>> previuos discussion. >>> >>> This submission adds better package names. Examples: >>> openscenegraph-2.7.7-Linux-i386.tar.gz (my ubuntu laptop), >>> openscenegraph-2.7.7-win32-x86-vc80.zip. >>> Compressed archive format is zip for windows and tar.gz for others. No >>> other options are given. >>> The packaging support is guarded to be available only with cmake-2.6.x >>> The default package target("package" on makefile projects and PACKAGE >>> in msvs) now generates openscenegraph-all-2.7.7-Linux-i386.tar.gz >>> because openscenegraph-2.7.7.Linux.i386.tar.gz is the name of the >>> applications >>> package >>> >>> The "Linux" on the package name is (according to cmake docs) what gets >>> reported from calling uname. I'm not sure what this will be on mac. On >>> windows I ignore the CMake var CMAKE_SYSTEM_NAME and sets this to >>> either win32 or win64 based on CMAKE_CL_64 >>> i386 is really reported as i686 but I change this because i read >>> somewhere that debian packages requires i386 over i686 so if we can >>> live with i386 we might be better prepared for generating DEBs >>> >>> There is more to do: >>> 1. yes I picked up the discussion on tgz on all platforms :-) This >>> gets complicated by the fact that cmake has encapsulated this in >>> CPack.ZIP.cmake which generates zip archives using 7zip so however >>> easy 7zip is to use I don't get direct access to the commandline that >>> cpack uses to call it. There are of course solutions but these will >>> require combination of cmake script and finding platform specific >>> programs that will possibly complicate readability and maintainability >>> just because we want a different file extension. Currently there are >>> other >>> ends >>> of the cpack support that need improvement so for windows we'll have >>> to live with zip for now. The best solution is better cmake support >>> for customizing how cmake invokes 7zip on windows. >>> >>> 2. Regarding the directory naming pointed out by Robert: I was hoping for >>> that >>> the CPACK_TOPLEVEL_TAG was the trick but no luck. The cmake.org has >>> been down today but as soon is it comes up i will download and compile >>> it myself to see what can be done for how we want to use it >>> >>> 3 Optional deb, rpm and visual installer (nsis) on windows. Creating >>> rpms can be created from command line like this: >>> cpack --config <builddir>/<CPackConfig-xxx.cmake> -G RPM >>> >>> 4 The compiler discovery may need some more advanced cmake scripting >>> that i'm currently not able to do (no windows at home). I relied on >>> the _MSC_VER macro (through the cmake var MSVC_VERSION) here but >>> according to >>> http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=213580 >>> it appears the _MSC_VER is 1400 regardless of service pack. This >>> doesn't make sense so Il'l check this on monday. >>> With this submission packages on windows will at least get vc80 or >>> vc90 appended. >>> >>> 5 I haven't found a suitable cmake variable to distinguish between 32 >>> and 64bit architectures on other platforms than windows >>> >>> Robert - Sorry I missed your q if I would be able to tackle your requests >>> earlier. I will do my best to make the cpack support 2.8.0 >>> worthy. >>> >>> cheers >>> Mattias >>> >>> On 12/12/08, Jean-Sébastien Guay <[email protected]> wrote: >>>> Hi Matthias, >>>> >>>>>>> And eventually vc90 may get its own SP1 >>>>>> Already done :-) >>>>> >>>>> First thought - you can't be serious ;-) >>>>> Now people are gonna start asking why my 3rdParty_dependencies_vc90 >>>>> don't >>>>> work!? >>>> >>>> Hehe, it's just a matter of time. :p >>>> >>>> Perhaps you should install SP1 and do some testing to see if your >>>> dependencies are compatible with both (you never know... What was true >>>> of vs80 - vs80sp1 is not necessarily true of vs90 - vs90sp1...) >>>> >>>> J-S >>>> -- >>>> ______________________________________________________ >>>> Jean-Sebastien Guay [email protected] >>>> http://www.cm-labs.com/ >>>> http://whitestar02.webhop.org/ >>>> _______________________________________________ >>>> osg-submissions mailing list >>>> [email protected] >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >>>> >>> >> >> _______________________________________________ >> osg-submissions mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> >> > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
