Re: [osg-users] Rethinking 3rd party dependencies?
Hi Philip, Robert, and all FYI, some devs and I started to add a CMake script to libcurl ; and the libcurl community seemed quite interested, yet not waiting for it. Unfortunately I didn't had time to finish the job for now. If you intend to work on it, you may have a look to what has been done (and/or ask me). I agree CMakePorts could be a nice idea for dependencies that don't already have a CMake script. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - "Philip Lowman" a écrit : > On Mon, Aug 31, 2009 at 4:43 AM, Robert Osfield < > robert.osfi...@gmail.com > wrote: > > > Hi Philip, > > I'm all for integrating CMakePorts support into OSG build. I'm I > correct in reading the cmakeports_osg.path that one would build the > OSG and have the external libs build automatically when required? > Currently .patch only lists jpeg, zlib and png. Is this just a > preliminary lists? Are others pending? > > Hi Robert, > > The way it is setup now you would enable an option and then pick the > directory where the ports exist on your system, then it would find any > that exist in the directory and build them if present. I do not have > it setup so that it would try to build the port if you don't already > have the dependency but this is an interesting idea. First I would > have to determine a safe way for Find3rdPartyDependencies.cmake and > CMakePortsSearch.cmake to interact with each other which currently > does not exist. > > Yes, only libjpeg, libpng, and zlib have been made available for the > moment. freetype & glut have been done but need packaging/testing. I > also plan to ensure this works for curl and tiff. > > -- > Philip Lowman > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rethinking 3rd party dependencies?
On Mon, Aug 31, 2009 at 4:43 AM, Robert Osfield wrote: > Hi Philip, > > I'm all for integrating CMakePorts support into OSG build. I'm I > correct in reading the cmakeports_osg.path that one would build the > OSG and have the external libs build automatically when required? > Currently .patch only lists jpeg, zlib and png. Is this just a > preliminary lists? Are others pending? Hi Robert, The way it is setup now you would enable an option and then pick the directory where the ports exist on your system, then it would find any that exist in the directory and build them if present. I do not have it setup so that it would try to build the port if you don't already have the dependency but this is an interesting idea. First I would have to determine a safe way for Find3rdPartyDependencies.cmake and CMakePortsSearch.cmake to interact with each other which currently does not exist. Yes, only libjpeg, libpng, and zlib have been made available for the moment. freetype & glut have been done but need packaging/testing. I also plan to ensure this works for curl and tiff. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rethinking 3rd party dependencies?
Hi Philip, I'm all for integrating CMakePorts support into OSG build. I'm I correct in reading the cmakeports_osg.path that one would build the OSG and have the external libs build automatically when required? Currently .patch only lists jpeg, zlib and png. Is this just a preliminary lists? Are others pending? Robert. On Fri, Aug 28, 2009 at 11:46 PM, Philip Lowman wrote: > While poring over thread after thread dealing with build dependencies on > Windows I had a weird thought a while back: computers are fast these days, > why not just build everything (including 3rd party dependencies) from > source? > > The way I see it, issues on Windows are going to get worse far before they > get any better. Issues like: > 1. Differing compiler versions (MSVC 7.1/8/9, MinGW 3.4/4.4) > 2. The need for Debug libraries with certain compilers > 3. The need for 32 and/or 64-bit libraries > 4. The occasional need for a complete static build > 5. The need/desire for some people to compile with /MT or _SECURE_SCL=0 on > MSVC > ...are likely not to be going away anytime soon and they can create a > confusing ecosystem. Also, security issues & library bugfixes tend to get > ignored once someone has that prebuilt library sitting off in CM somewhere. > > So I cmakeified libpng, zlib, and libjpeg (building on some work previously > done by Luigi Calori and others) and wrapped them in ZIP files called > CMakeports. The three put together take about 5 seconds total to build on > my 3 year old core2 duo. They are available at the website below. > > http://code.google.com/p/cmakeports/ > > I've integrated and tested* the 3 ports with OSG using osgviewer --image, > and things seem to be working fine. I'd like to submit this to > osg-submissions assuming there is enough interest in the idea. I'm doubtful > this could satisfy 100% of the dependencies people might want to use with > the OSG, but I'm optimistic it could cover the major ones (png, jpg, zlib, > tiff, & freetype seem like no-brainers to me). > > * I have tested: > MSVC9 32-bit DYNAMIC_OPENSCENEGRAPH=ON (Debug & Release) > MinGW 3.4. > * I have partially tested: > MSVC9 32-bit DYNAMIC_OPENSCENEGRAPH=OFF (code compiles but haven't tried > building/linking a custom viewer) > * I have not tested: > MSVC8 > MSVC9 64-bit > MinGW 4.4.0 > > -- > Philip Lowman > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rethinking 3rd party dependencies?
On Sat, Aug 29, 2009 at 9:03 AM, Jean-Sébastien Guay < jean-sebastien.g...@cm-labs.com> wrote: > Philip, I like your idea of making CMake setups for these dependencies, it > kind of resembles automake/autoconf. The problem is that the CMake files > won't be managed by the upstream project, but by another external group > (us). Won't the same problem happen when we decide to change versions? This is a good point. I think the plan is to submit the CMakeLists.txt to the upstream project for them to manage (should they choose to). libpng betas at least now have CMakeLists.txt, for example. But I concede that we (whoever volunteers on the CMakePorts project) will have to maintain some of the CMakeLists.txt files, but this should hopefully be a fairly minor effort. Each CMakePort does have a maintainer as well who should be subscribed to the project on freshmeat or an announce list. http://code.google.com/p/cmakeports/wiki/AvailablePorts Maybe I'm over-evaluating the risk, since the version will likely be bumped > only seldom and when it is, only one person will have to check that > everything still builds correctly and fix it if it doesn't, and then commit > the changes to the CMake files for everyone to use. But still, I wouldn't > want to be that person. Luckily most of these projects are ABI/API stable so changes to OSG should be in theory non-existent. Changes to the CMakeLists.txt to build them will be required, but I suspect that they will be relatively minor. Anyways, that's my 2 cents on the subject, I like the idea but it carries > some risks, we just have to be aware before we decide to support this > completely... Yes, I agree. It probably should be an experimental thing if we decide to try it out and certainly would be disabled by default. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rethinking 3rd party dependencies?
Hi all, Making a 3rtParty repository like the one made by Mike Weiblen but with all the dependencies and their CMake scripts is a good idea, I vote for this solution ! :) Cheers, On Sat, Aug 29, 2009 at 5:25 PM, Chris 'Xenon' Hanson wrote: > Philip Lowman wrote: > > So I cmakeified libpng, zlib, and libjpeg (building on some work > > previously done by Luigi Calori and others) and wrapped them in ZIP > > files called CMakeports. The three put together take about 5 seconds > > total to build on my 3 year old core2 duo. They are available at the > > website below. > > http://code.google.com/p/cmakeports/ > > I think this is a good idea too. > > These three libraries have been very stable for a long time, with only > bug/security > fixes, so they're relatively easy to obtain and build, and things aren't > likely to be > changing much (unlike something such as COLLADA). > > -- > Chris 'Xenon' Hanson, omo sanza lettere Xenon > AlphaPixel.com > PixelSense Landsat processing now available! > http://www.alphapixel.com/demos/ > "There is no Truth. There is only Perception. To Perceive is to Exist." - > Xen > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rethinking 3rd party dependencies?
Philip Lowman wrote: > So I cmakeified libpng, zlib, and libjpeg (building on some work > previously done by Luigi Calori and others) and wrapped them in ZIP > files called CMakeports. The three put together take about 5 seconds > total to build on my 3 year old core2 duo. They are available at the > website below. > http://code.google.com/p/cmakeports/ I think this is a good idea too. These three libraries have been very stable for a long time, with only bug/security fixes, so they're relatively easy to obtain and build, and things aren't likely to be changing much (unlike something such as COLLADA). -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ "There is no Truth. There is only Perception. To Perceive is to Exist." - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rethinking 3rd party dependencies?
Hi Philip, Sherman, I agree with the basic principle that building everything from source removes lots of uncertainty from the equation. The only problem I have with that is that whenever you want to bump the version number of one of the dependencies, you run the risk that some changes in the sources/build system will break your build, and then you have to try to debug an unfamiliar project or build system. In building the dependencies for OSG at work, I remember that out of 7 dependencies, maybe 3 used Visual Studio .sln/.dsw projects, the others used nmake. For those that used nmake, their nmake scripts often varied a lot, so where to tweak the build settings (for building debug/release, and for /MD vs /MDD, etc.) varied. Nothing is standardized - I know people tend to dislike automake/autoconf but they really simplify this kind of thing on Linux. It's just a lot of hassle that you have to go through every time you bump the version number of some dependency. If I were able to avoid that, I would be glad to. In the end, there's a finite number of dependencies and a finite number of different build configurations, so why not just list them and assign them to people, and then everyone could use them once they're built and uploaded to openscenegraph.org? We could assign for example Win32 MSVC8 (debug+release) to one person, Win64 MSVC8 (debug+release) to another, etc. Philip, I like your idea of making CMake setups for these dependencies, it kind of resembles automake/autoconf. The problem is that the CMake files won't be managed by the upstream project, but by another external group (us). Won't the same problem happen when we decide to change versions? Maybe I'm over-evaluating the risk, since the version will likely be bumped only seldom and when it is, only one person will have to check that everything still builds correctly and fix it if it doesn't, and then commit the changes to the CMake files for everyone to use. But still, I wouldn't want to be that person. Anyways, that's my 2 cents on the subject, I like the idea but it carries some risks, we just have to be aware before we decide to support this completely... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rethinking 3rd party dependencies?
We also build every thing including all third party and all their dependenacies from source both 32 bit and 64 bit. in the end it simply makes life easier From: osg-users-boun...@lists.openscenegraph.org on behalf of sherman wilcox Sent: Sat 8/29/2009 12:49 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Rethinking 3rd party dependencies? I build *everything* from source. I use Python scripts to automate the process too. It's relatively straightforward to setup and is very reliable. Fully automated. I can call one Python script that will check out all source code, compile all OSG and project specific dependencies, compile OSG, compile my application(s) and issue a release. Python is awesome. Could do the same thing with Perl but once I started to use Python I never looked back. Using CMake from the command line is easy as well - very straightforward. I highly recommend compiling all from source. On Fri, Aug 28, 2009 at 5:46 PM, Philip Lowman wrote: > While poring over thread after thread dealing with build dependencies on > Windows I had a weird thought a while back: computers are fast these days, > why not just build everything (including 3rd party dependencies) from > source? > > The way I see it, issues on Windows are going to get worse far before they > get any better. Issues like: > 1. Differing compiler versions (MSVC 7.1/8/9, MinGW 3.4/4.4) > 2. The need for Debug libraries with certain compilers > 3. The need for 32 and/or 64-bit libraries > 4. The occasional need for a complete static build > 5. The need/desire for some people to compile with /MT or _SECURE_SCL=0 on > MSVC > ...are likely not to be going away anytime soon and they can create a > confusing ecosystem. Also, security issues & library bugfixes tend to get > ignored once someone has that prebuilt library sitting off in CM somewhere. > > So I cmakeified libpng, zlib, and libjpeg (building on some work previously > done by Luigi Calori and others) and wrapped them in ZIP files called > CMakeports. The three put together take about 5 seconds total to build on > my 3 year old core2 duo. They are available at the website below. > > http://code.google.com/p/cmakeports/ > > I've integrated and tested* the 3 ports with OSG using osgviewer --image, > and things seem to be working fine. I'd like to submit this to > osg-submissions assuming there is enough interest in the idea. I'm doubtful > this could satisfy 100% of the dependencies people might want to use with > the OSG, but I'm optimistic it could cover the major ones (png, jpg, zlib, > tiff, & freetype seem like no-brainers to me). > > * I have tested: > MSVC9 32-bit DYNAMIC_OPENSCENEGRAPH=ON (Debug & Release) > MinGW 3.4. > * I have partially tested: > MSVC9 32-bit DYNAMIC_OPENSCENEGRAPH=OFF (code compiles but haven't tried > building/linking a custom viewer) > * I have not tested: > MSVC8 > MSVC9 64-bit > MinGW 4.4.0 > > -- > Philip Lowman > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org <>___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rethinking 3rd party dependencies?
I build *everything* from source. I use Python scripts to automate the process too. It's relatively straightforward to setup and is very reliable. Fully automated. I can call one Python script that will check out all source code, compile all OSG and project specific dependencies, compile OSG, compile my application(s) and issue a release. Python is awesome. Could do the same thing with Perl but once I started to use Python I never looked back. Using CMake from the command line is easy as well - very straightforward. I highly recommend compiling all from source. On Fri, Aug 28, 2009 at 5:46 PM, Philip Lowman wrote: > While poring over thread after thread dealing with build dependencies on > Windows I had a weird thought a while back: computers are fast these days, > why not just build everything (including 3rd party dependencies) from > source? > > The way I see it, issues on Windows are going to get worse far before they > get any better. Issues like: > 1. Differing compiler versions (MSVC 7.1/8/9, MinGW 3.4/4.4) > 2. The need for Debug libraries with certain compilers > 3. The need for 32 and/or 64-bit libraries > 4. The occasional need for a complete static build > 5. The need/desire for some people to compile with /MT or _SECURE_SCL=0 on > MSVC > ...are likely not to be going away anytime soon and they can create a > confusing ecosystem. Also, security issues & library bugfixes tend to get > ignored once someone has that prebuilt library sitting off in CM somewhere. > > So I cmakeified libpng, zlib, and libjpeg (building on some work previously > done by Luigi Calori and others) and wrapped them in ZIP files called > CMakeports. The three put together take about 5 seconds total to build on > my 3 year old core2 duo. They are available at the website below. > > http://code.google.com/p/cmakeports/ > > I've integrated and tested* the 3 ports with OSG using osgviewer --image, > and things seem to be working fine. I'd like to submit this to > osg-submissions assuming there is enough interest in the idea. I'm doubtful > this could satisfy 100% of the dependencies people might want to use with > the OSG, but I'm optimistic it could cover the major ones (png, jpg, zlib, > tiff, & freetype seem like no-brainers to me). > > * I have tested: > MSVC9 32-bit DYNAMIC_OPENSCENEGRAPH=ON (Debug & Release) > MinGW 3.4. > * I have partially tested: > MSVC9 32-bit DYNAMIC_OPENSCENEGRAPH=OFF (code compiles but haven't tried > building/linking a custom viewer) > * I have not tested: > MSVC8 > MSVC9 64-bit > MinGW 4.4.0 > > -- > Philip Lowman > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rethinking 3rd party dependencies?
While poring over thread after thread dealing with build dependencies on Windows I had a weird thought a while back: computers are fast these days, why not just build everything (including 3rd party dependencies) from source? The way I see it, issues on Windows are going to get worse far before they get any better. Issues like: 1. Differing compiler versions (MSVC 7.1/8/9, MinGW 3.4/4.4) 2. The need for Debug libraries with certain compilers 3. The need for 32 and/or 64-bit libraries 4. The occasional need for a complete static build 5. The need/desire for some people to compile with /MT or _SECURE_SCL=0 on MSVC ...are likely not to be going away anytime soon and they can create a confusing ecosystem. Also, security issues & library bugfixes tend to get ignored once someone has that prebuilt library sitting off in CM somewhere. So I cmakeified libpng, zlib, and libjpeg (building on some work previously done by Luigi Calori and others) and wrapped them in ZIP files called CMakeports. The three put together take about 5 seconds total to build on my 3 year old core2 duo. They are available at the website below. http://code.google.com/p/cmakeports/ I've integrated and tested* the 3 ports with OSG using osgviewer --image, and things seem to be working fine. I'd like to submit this to osg-submissions assuming there is enough interest in the idea. I'm doubtful this could satisfy 100% of the dependencies people might want to use with the OSG, but I'm optimistic it could cover the major ones (png, jpg, zlib, tiff, & freetype seem like no-brainers to me). * I have tested: MSVC9 32-bit DYNAMIC_OPENSCENEGRAPH=ON (Debug & Release) MinGW 3.4. * I have partially tested: MSVC9 32-bit DYNAMIC_OPENSCENEGRAPH=OFF (code compiles but haven't tried building/linking a custom viewer) * I have not tested: MSVC8 MSVC9 64-bit MinGW 4.4.0 -- Philip Lowman cmakeports_osg.patch Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
