From: Richard M. <jp...@gm...> - 2009-10-07 23:30:13
|
Hello all, I'm interested in packaging gearbox for Fedora. I'm working on getting the specfile together for submission, and I have a few questions. 1. The LICENCE file is unclear as to which versions of the GPL/LGPL are in use. Some of the source headers seem to indicate LGPLv3+, but I'd like to clarify before I go further. 2. Is there any reason the cmake files are installed into the /$prefix/lib/gearbox and not somewhere like $prefix/share/cmake/Modules? That seems to be where most packages put their CMake files. Thanks, Rich Mattes |
From: Geoffrey B. <geo...@ai...> - 2009-10-07 23:51:36
|
Having a package for Fedora would be great. Thanks for doing the hard work to make it! 1. As the license depends on each library, in the CMake script for each library there is a call to set the license used by that library. I guess these should be clarified by adding version numbers as well? Would that add the clarification you need? 2. That looks like a bug. Most of the Gearbox CMake scripts are installed to ${prefix}/share (although they're currently going into a gearbox/cmake subdir, that should probably be changed). I'll fix this today. Geoff Richard Mattes wrote: > Hello all, > > I'm interested in packaging gearbox for Fedora. I'm working on getting > the specfile together for submission, and I have a few questions. > > 1. The LICENCE file is unclear as to which versions of the GPL/LGPL are > in use. Some of the source headers seem to indicate LGPLv3+, but I'd > like to clarify before I go further. > > 2. Is there any reason the cmake files are installed into the > /$prefix/lib/gearbox and not somewhere like $prefix/share/cmake/Modules? > That seems to be where most packages put their CMake files. |
From: Richard M. <jp...@gm...> - 2009-10-08 00:24:45
|
Hi Geoff, The version numbers are the only thing I was unclear on. RPM's like to specify which version of the L/GPL are used, as well as whether it's compatible with later licenses (i.e. GPLv2+). I don't want to make any mistakes in this part. I misspoke when i said ${prefix}/lib/gearbox, i did mean ${prefix}/share, but my concern remains that it's not landing in the ${prefix}/share/cmake/Modules path. I'm currently working on packaging release 9.07, with the intent of being able to build things like Player 3.0 against it in the future. I'm getting in touch with the current maintainers involved in the Fedora Robotics Special Interest Group and doing the legwork to get modern versions of Player, Stage, Gazebo, Gearbox, etc. into Fedora. To fix the cmake and licensing files, I'll probably just add patches against the 9.07 release until you guys make another release. I'd also be happy to add files like AUTHORS if you wish to add them. Thanks, Rich Mattes On 10/07/2009 07:51 PM, Geoffrey Biggs wrote: > Having a package for Fedora would be great. Thanks for doing the hard > work to make it! > > 1. As the license depends on each library, in the CMake script for each > library there is a call to set the license used by that library. I guess > these should be clarified by adding version numbers as well? Would that > add the clarification you need? > > 2. That looks like a bug. Most of the Gearbox CMake scripts are > installed to ${prefix}/share (although they're currently going into a > gearbox/cmake subdir, that should probably be changed). I'll fix this today. > > Geoff > > Richard Mattes wrote: >> Hello all, >> >> I'm interested in packaging gearbox for Fedora. I'm working on getting >> the specfile together for submission, and I have a few questions. >> >> 1. The LICENCE file is unclear as to which versions of the GPL/LGPL are >> in use. Some of the source headers seem to indicate LGPLv3+, but I'd >> like to clarify before I go further. >> >> 2. Is there any reason the cmake files are installed into the >> /$prefix/lib/gearbox and not somewhere like $prefix/share/cmake/Modules? >> That seems to be where most packages put their CMake files. > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Gearbox-devel mailing list > Gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearbox-devel |
From: Richard M. <jp...@gm...> - 2009-10-11 21:15:51
|
Hi, I just about ready to submit gearbox 9.07 for consideration in Fedora. I just have a couple of questions: - When you say GPL, do you mean GPLv3+? I think that LGPLv3+ is what you mean by LGPL, since some of the headers specify "version 3 or later." - Do you guys support building for x86_64? It looks like most of the cmake files have /lib/ hardcoded, so installing to /lib64/ isn't an option? Also, it looks like ice isn't available for ppc64 in Fedora, so I might not be able to target that architecture either. Thanks, Rich On 10/07/2009 07:51 PM, Geoffrey Biggs wrote: > Having a package for Fedora would be great. Thanks for doing the hard > work to make it! > > 1. As the license depends on each library, in the CMake script for each > library there is a call to set the license used by that library. I guess > these should be clarified by adding version numbers as well? Would that > add the clarification you need? > > 2. That looks like a bug. Most of the Gearbox CMake scripts are > installed to ${prefix}/share (although they're currently going into a > gearbox/cmake subdir, that should probably be changed). I'll fix this today. > > Geoff > > Richard Mattes wrote: >> Hello all, >> >> I'm interested in packaging gearbox for Fedora. I'm working on getting >> the specfile together for submission, and I have a few questions. >> >> 1. The LICENCE file is unclear as to which versions of the GPL/LGPL are >> in use. Some of the source headers seem to indicate LGPLv3+, but I'd >> like to clarify before I go further. >> >> 2. Is there any reason the cmake files are installed into the >> /$prefix/lib/gearbox and not somewhere like $prefix/share/cmake/Modules? >> That seems to be where most packages put their CMake files. > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Gearbox-devel mailing list > Gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearbox-devel |
From: Alex M. <al...@ca...> - 2009-10-27 02:55:51
|
On Thu, Oct 8, 2009 at 10:51 AM, Geoffrey Biggs <geo...@ai...> wrote: > 2. That looks like a bug. Most of the Gearbox CMake scripts are > installed to ${prefix}/share (although they're currently going into a > gearbox/cmake subdir, that should probably be changed). I'll fix this today. Hey Geoff, thanks for moving the installation point. I think that we should mark our *.cmake somehow if we are dumping them into a common directory (e.g. /usr/local/cmake/Modules/ ). Putting something like Assert.cmake in common place is pretty rude. Should prepend Gbx to all of them? /usr/local/cmake/Modules/GbxAssert.cmake ??? alex |
From: Geoffrey B. <geo...@ai...> - 2009-10-27 03:02:57
|
I thought the same thing when I moved them, but didn't get around to figuring out a solution. In hindsight, prepending "Gbx" to them is pretty obvious. :) I agree with that solution. Geoff Alex Makarenko wrote: > On Thu, Oct 8, 2009 at 10:51 AM, Geoffrey Biggs > <geo...@ai...> wrote: > >> 2. That looks like a bug. Most of the Gearbox CMake scripts are >> installed to ${prefix}/share (although they're currently going into a >> gearbox/cmake subdir, that should probably be changed). I'll fix this today. > > Hey Geoff, > thanks for moving the installation point. > > I think that we should mark our *.cmake somehow if we are dumping them > into a common directory (e.g. /usr/local/cmake/Modules/ ). > Putting something like Assert.cmake in common place is pretty rude. > Should prepend Gbx to all of them? > > /usr/local/cmake/Modules/GbxAssert.cmake ??? |
From: Alex B. <a.b...@ma...> - 2009-10-27 03:31:04
|
> I think that we should mark our *.cmake somehow if we are dumping them > into a common directory (e.g. /usr/local/cmake/Modules/ ). > Putting something like Assert.cmake in common place is pretty rude. > Should prepend Gbx to all of them? > > /usr/local/cmake/Modules/GbxAssert.cmake ??? I like having the gearbox ones easy to find. Another option would put them into a subdir: /usr/local/cmake/Modules/gearbox/Assert.cmake ??? Alex |
From: Rich M. <jp...@gm...> - 2009-10-28 04:55:03
|
I just submitted all of the cmake patches I came up with while packaging for Fedora. I was wondering if it's necessary to dump all of the project's .cmake files into the Modules directory, or if you can get away with just installing gearbox-config.cmake, gearbox-config-external.cmake, gearbox-targets*, etc (the files that were showing up in ${prefix}/lib/gearbox for a while). These cmake files are configured at build time in WritePackageConfig.cmake or by Cmake during the install process. They seem to contain correct install path information that reflects all of the cmake build options. The rest of the .cmake files look like they're only used during the build process, and I don't see how they are useful otherwise. I only added the gearbox-*.cmake files in the Fedora packages, and put them in ${prefix}/share/cmake/Modules. Another option could be to take the approach Player uses, and make files like UseGearbox.cmake, UseFlexiport.cmake, etc. that have the correct paths to the library and include directories hard coded (configured at install time). That functionality might be mostly provided by the gearbox-*.cmake files already though. Also, I suggest that if the libraries are installed to a non-standard library location (like ${prefix}/lib/gearbox) that you add a config file to /etc/ld.so.conf.d/ that points back to the gearbox library path. That way you don't have to modify your LD_LIBRARY_PATH to resolve interdependent libraries at runtime. Rich Geoff Biggs wrote: > Does CMake look in subdirectories of Modules automatically? If it does, > this would also be a good solution. Otherwise, I vote for the prefix > method as it is easier to use. > > Geoff > > Alex Brooks wrote: > >>> I think that we should mark our *.cmake somehow if we are dumping them >>> into a common directory (e.g. /usr/local/cmake/Modules/ ). >>> Putting something like Assert.cmake in common place is pretty rude. >>> Should prepend Gbx to all of them? >>> >>> /usr/local/cmake/Modules/GbxAssert.cmake ??? >>> >> I like having the gearbox ones easy to find. Another option would put them >> into a subdir: >> /usr/local/cmake/Modules/gearbox/Assert.cmake ??? >> > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Gearbox-devel mailing list > Gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearbox-devel > |
From: Alex M. <al...@ca...> - 2009-10-28 13:07:09
|
Hi Rich, > I just submitted all of the cmake patches I came up with while packaging > for Fedora. sorry, I didn't understand: where did you submit the patches? > I was wondering if it's necessary to dump all of the > project's .cmake files into the Modules directory, or if you can get > away with just installing gearbox-config.cmake, This is not enough, we reuse all of the infrastructure cmake macros in another open-source project called Orca. orca-robotics.sf.net > gearbox-config-external.cmake, gearbox-targets*, etc (the files that > were showing up in ${prefix}/lib/gearbox for a while). I hope they are still showing up there because without these Orca will not build. alex |
From: Alex M. <ale...@gm...> - 2009-10-12 01:59:35
|
Hi Rich, thanks for taking this on. > 2. Is there any reason the cmake files are installed into the > /$prefix/lib/gearbox and not somewhere like $prefix/share/cmake/Modules? > That seems to be where most packages put their CMake files. The CMake files installed in the lib directory are the special files related to package-config, a mechanism for one CMake project depend on another. We use this extensively. The recommended installation point for these is in fact: ${PREFIX}/lib/myproj/myproj-targets.cmake see http://www.itk.org/Wiki/CMake_2.6_Notes#Exporting_from_an_Installation_Tree cheers, alex |
From: Alex M. <ale...@gm...> - 2009-10-12 03:21:36
|
another clarification regarding the gearbox-config*.cmake and gearbox-targets*.cmake files. they are used when you a) build another project which relies on gearbox, and b) that project also uses CMake therefore, these files could be part of a "gearbox-dev" package, similar to header files. are you planning on putting together a dev package? alex On 10/12/09, Alex Makarenko <ale...@gm...> wrote: > Hi Rich, > thanks for taking this on. > >> 2. Is there any reason the cmake files are installed into the >> /$prefix/lib/gearbox and not somewhere like $prefix/share/cmake/Modules? >> That seems to be where most packages put their CMake files. > > The CMake files installed in the lib directory are the special files > related to package-config, a mechanism for one CMake project depend on > another. We use this extensively. > > The recommended installation point for these is in fact: > ${PREFIX}/lib/myproj/myproj-targets.cmake > see > http://www.itk.org/Wiki/CMake_2.6_Notes#Exporting_from_an_Installation_Tree > > cheers, > alex > |
From: Rich M. <jp...@gm...> - 2009-10-12 03:51:32
|
I am creating the packages gearbox and gearbox-devel. The base gearbox package only contains the LICENSE file and the versioned libraries. The -devel package contains the plain .so files, the pkg-config scripts, the include headers, the code for the example programs (installed at ${prefix}/share), and the doxygen-generated documentation (which looks to be a mirror of your project site). With build-examples enabled, the compiled binaries try to install themselves to ${prefix}/bin, but i opt not to include those, as the source is readily available at ${prefix}/share should anyone need them. As it stands, I can only target i386 and x86_64. Ice is not built for ppc64 in Fedora (because of many missing deps), so that arch is out. And the ppc termios bits don't include CIBAUD, which causes the gbxserialacfr/serial.cpp build to fail (line 285). x86_64 is another story, since libraries should be installed to lib64 instead of lib, but I'm working on adding cmake logic to detect the host processor and set the path accordingly. Most of it I fixed by changing the libdir in SetupDirectories.cmake, but i still have to fix the generated pkg-config scripts and figure out where the path for gearbox-config*.cmake is being set (it seems to be separate from the rest of the project). I'll probably end up grepping through the files for hardcoded /lib/ paths and adjusting them as necessary. Rich On Sun, Oct 11, 2009 at 11:21 PM, Alex Makarenko <ale...@gm...> wrote: > another clarification regarding the gearbox-config*.cmake and > gearbox-targets*.cmake files. > > they are used when you > a) build another project which relies on gearbox, and > b) that project also uses CMake > > therefore, these files could be part of a "gearbox-dev" package, > similar to header files. are you planning on putting together a dev > package? > > alex > > > On 10/12/09, Alex Makarenko <ale...@gm...> wrote: >> Hi Rich, >> thanks for taking this on. >> >>> 2. Is there any reason the cmake files are installed into the >>> /$prefix/lib/gearbox and not somewhere like $prefix/share/cmake/Modules? >>> That seems to be where most packages put their CMake files. >> >> The CMake files installed in the lib directory are the special files >> related to package-config, a mechanism for one CMake project depend on >> another. We use this extensively. >> >> The recommended installation point for these is in fact: >> ${PREFIX}/lib/myproj/myproj-targets.cmake >> see >> http://www.itk.org/Wiki/CMake_2.6_Notes#Exporting_from_an_Installation_Tree >> >> cheers, >> alex >> > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Gearbox-devel mailing list > Gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearbox-devel > |
From: Alex M. <ale...@gm...> - 2009-10-12 04:34:03
|
excellent! thanks for your efforts. we'll update our licences shortly. alex On 10/12/09, Rich Mattes <jp...@gm...> wrote: > I am creating the packages gearbox and gearbox-devel. The base gearbox > package only contains the LICENSE file and the versioned libraries. The > -devel package contains the plain .so files, the pkg-config scripts, the > include headers, the code for the example programs (installed at > ${prefix}/share), and the doxygen-generated documentation (which looks to > be > a mirror of your project site). With build-examples enabled, the compiled > binaries try to install themselves to ${prefix}/bin, but i opt not to > include those, as the source is readily available at ${prefix}/share should > anyone need them. > > As it stands, I can only target i386 and x86_64. Ice is not built for > ppc64 > in Fedora (because of many missing deps), so that arch is out. And the ppc > termios bits don't include CIBAUD, which causes the > gbxserialacfr/serial.cpp > build to fail (line 285). x86_64 is another story, since libraries should > be installed to lib64 instead of lib, but I'm working on adding cmake logic > to detect the host processor and set the path accordingly. Most of it I > fixed by changing the libdir in SetupDirectories.cmake, but i still have to > fix the generated pkg-config scripts and figure out where the path for > gearbox-config*.cmake is being set (it seems to be separate from the rest > of > the project). I'll probably end up grepping through the files for > hardcoded > /lib/ paths and adjusting them as necessary. > > Rich > > > On Sun, Oct 11, 2009 at 11:21 PM, Alex Makarenko <ale...@gm...> > wrote: >> another clarification regarding the gearbox-config*.cmake and >> gearbox-targets*.cmake files. >> >> they are used when you >> a) build another project which relies on gearbox, and >> b) that project also uses CMake >> >> therefore, these files could be part of a "gearbox-dev" package, >> similar to header files. are you planning on putting together a dev >> package? >> >> alex >> >> >> On 10/12/09, Alex Makarenko <ale...@gm...> wrote: >>> Hi Rich, >>> thanks for taking this on. >>> >>>> 2. Is there any reason the cmake files are installed into the >>>> /$prefix/lib/gearbox and not somewhere like >>>> $prefix/share/cmake/Modules? >>>> That seems to be where most packages put their CMake files. >>> >>> The CMake files installed in the lib directory are the special files >>> related to package-config, a mechanism for one CMake project depend on >>> another. We use this extensively. >>> >>> The recommended installation point for these is in fact: >>> ${PREFIX}/lib/myproj/myproj-targets.cmake >>> see >>> > http://www.itk.org/Wiki/CMake_2.6_Notes#Exporting_from_an_Installation_Tree >>> >>> cheers, >>> alex >>> >> >> > ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Gearbox-devel mailing list >> Gea...@li... >> https://lists.sourceforge.net/lists/listinfo/gearbox-devel >> > |
From: Rich M. <jp...@gm...> - 2009-10-20 11:03:53
|
Hello, Just wondering where you are with the licenses. Thanks, Rich Alex Makarenko wrote: > excellent! > thanks for your efforts. > > we'll update our licences shortly. > alex > > > On 10/12/09, Rich Mattes <jp...@gm...> wrote: > >> I am creating the packages gearbox and gearbox-devel. The base gearbox >> package only contains the LICENSE file and the versioned libraries. The >> -devel package contains the plain .so files, the pkg-config scripts, the >> include headers, the code for the example programs (installed at >> ${prefix}/share), and the doxygen-generated documentation (which looks to >> be >> a mirror of your project site). With build-examples enabled, the compiled >> binaries try to install themselves to ${prefix}/bin, but i opt not to >> include those, as the source is readily available at ${prefix}/share should >> anyone need them. >> >> As it stands, I can only target i386 and x86_64. Ice is not built for >> ppc64 >> in Fedora (because of many missing deps), so that arch is out. And the ppc >> termios bits don't include CIBAUD, which causes the >> gbxserialacfr/serial.cpp >> build to fail (line 285). x86_64 is another story, since libraries should >> be installed to lib64 instead of lib, but I'm working on adding cmake logic >> to detect the host processor and set the path accordingly. Most of it I >> fixed by changing the libdir in SetupDirectories.cmake, but i still have to >> fix the generated pkg-config scripts and figure out where the path for >> gearbox-config*.cmake is being set (it seems to be separate from the rest >> of >> the project). I'll probably end up grepping through the files for >> hardcoded >> /lib/ paths and adjusting them as necessary. >> >> Rich >> >> >> On Sun, Oct 11, 2009 at 11:21 PM, Alex Makarenko <ale...@gm...> >> wrote: >> >>> another clarification regarding the gearbox-config*.cmake and >>> gearbox-targets*.cmake files. >>> >>> they are used when you >>> a) build another project which relies on gearbox, and >>> b) that project also uses CMake >>> >>> therefore, these files could be part of a "gearbox-dev" package, >>> similar to header files. are you planning on putting together a dev >>> package? >>> >>> alex >>> >>> >>> On 10/12/09, Alex Makarenko <ale...@gm...> wrote: >>> >>>> Hi Rich, >>>> thanks for taking this on. >>>> >>>> >>>>> 2. Is there any reason the cmake files are installed into the >>>>> /$prefix/lib/gearbox and not somewhere like >>>>> $prefix/share/cmake/Modules? >>>>> That seems to be where most packages put their CMake files. >>>>> >>>> The CMake files installed in the lib directory are the special files >>>> related to package-config, a mechanism for one CMake project depend on >>>> another. We use this extensively. >>>> >>>> The recommended installation point for these is in fact: >>>> ${PREFIX}/lib/myproj/myproj-targets.cmake >>>> see >>>> >>>> >> http://www.itk.org/Wiki/CMake_2.6_Notes#Exporting_from_an_Installation_Tree >> >>>> cheers, >>>> alex >>>> >>>> >>> >> ------------------------------------------------------------------------------ >> >>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>> http://p.sf.net/sfu/devconference >>> _______________________________________________ >>> Gearbox-devel mailing list >>> Gea...@li... >>> https://lists.sourceforge.net/lists/listinfo/gearbox-devel >>> >>> > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Gearbox-devel mailing list > Gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearbox-devel > |
From: Michael M. <m....@ca...> - 2009-10-20 14:08:41
|
Hi Rich, Rich Mattes wrote: > Just wondering where you are with the licenses. I've just spent an hour looking into licensing and now my head hurts ;-). First off, each of the libraries in gearbox could have a different license, see <http://gearbox.sourceforge.net/gbx_doc_principles.html#gbx_doc_principles_operation_lifecycle_submit>: "License: Must specify _an_ open source license." That most are LGPL is accidental. For the current situation: - Geoff Biggs maintains FlexiPort and libhokuyo_aist. All his headers mention LGPL v3, so that's clear. - Alex Makarenko, Alex Brooks, Tobi Kaupp and myself maintain the various gbx*acfr libraries and the two example libraries. We have one library (libGbxAdvancedExample) which is GPL, the rest are stated as LGPL. The single GPL is probably plain and simply a mistake, or Alex wanted to make the point that one is indeed free to pick _any_ open source license, I'll clarify that. With LGPL I am under the impression that that means any of the original LGPL (L as in Library, aka LGPL2) or successors, at the convenience of the user. I guess we could make that clear with LGPL v2+ or some such. So, after skimming the Fedora licensing guidelines I'd guess you have two choices: 1) LGPLv3+ _and_ LGPLv2+ 2) put the whole package under LGPLv3+ (i.e. re-licensing the gbx*acfr gear under the later license) Scheme 1) might be safer, since it can be extended if someone adds a BSD library. Cheers, Michael |
From: Geoffrey B. <geo...@ai...> - 2009-10-20 23:07:02
|
For what it's worth, I updated the CMakeLists.txt files of my libraries to specify an exact version of the license for the LICENSE file. Geoff Michael Moser wrote: > Hi Rich, > > Rich Mattes wrote: >> Just wondering where you are with the licenses. > > I've just spent an hour looking into licensing and now my head hurts ;-). > > First off, each of the libraries in gearbox could have a different > license, see > <http://gearbox.sourceforge.net/gbx_doc_principles.html#gbx_doc_principles_operation_lifecycle_submit>: > "License: Must specify _an_ open source license." That most are LGPL is > accidental. > > For the current situation: > - Geoff Biggs maintains FlexiPort and libhokuyo_aist. All his headers > mention LGPL v3, so that's clear. > > - Alex Makarenko, Alex Brooks, Tobi Kaupp and myself maintain the > various gbx*acfr libraries and the two example libraries. We have one > library (libGbxAdvancedExample) which is GPL, the rest are stated as > LGPL. The single GPL is probably plain and simply a mistake, or Alex > wanted to make the point that one is indeed free to pick _any_ open > source license, I'll clarify that. > With LGPL I am under the impression that that means any of the original > LGPL (L as in Library, aka LGPL2) or successors, at the convenience of > the user. I guess we could make that clear with LGPL v2+ or some such. > > So, after skimming the Fedora licensing guidelines I'd guess you have > two choices: > 1) LGPLv3+ _and_ LGPLv2+ > 2) put the whole package under LGPLv3+ (i.e. re-licensing the gbx*acfr > gear under the later license) > > Scheme 1) might be safer, since it can be extended if someone adds a BSD > library. |
From: Alex M. <al...@ca...> - 2009-10-28 13:17:32
|
following up to Michael's research... I've modified all ACFR's license statements to GPL2+ LGPL2+ alex On Wed, Oct 21, 2009 at 12:50 AM, Michael Moser <m....@ca...> wrote: > Hi Rich, > > Rich Mattes wrote: >> Just wondering where you are with the licenses. > > I've just spent an hour looking into licensing and now my head hurts ;-). > > First off, each of the libraries in gearbox could have a different > license, see > <http://gearbox.sourceforge.net/gbx_doc_principles.html#gbx_doc_principles_operation_lifecycle_submit>: > "License: Must specify _an_ open source license." That most are LGPL is > accidental. > > For the current situation: > - Geoff Biggs maintains FlexiPort and libhokuyo_aist. All his headers > mention LGPL v3, so that's clear. > > - Alex Makarenko, Alex Brooks, Tobi Kaupp and myself maintain the > various gbx*acfr libraries and the two example libraries. We have one > library (libGbxAdvancedExample) which is GPL, the rest are stated as > LGPL. The single GPL is probably plain and simply a mistake, or Alex > wanted to make the point that one is indeed free to pick _any_ open > source license, I'll clarify that. > With LGPL I am under the impression that that means any of the original > LGPL (L as in Library, aka LGPL2) or successors, at the convenience of > the user. I guess we could make that clear with LGPL v2+ or some such. > > So, after skimming the Fedora licensing guidelines I'd guess you have > two choices: > 1) LGPLv3+ _and_ LGPLv2+ > 2) put the whole package under LGPLv3+ (i.e. re-licensing the gbx*acfr > gear under the later license) > > Scheme 1) might be safer, since it can be extended if someone adds a BSD > library. > > > Cheers, > Michael > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Gearbox-devel mailing list > Gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearbox-devel > |
From: Geoff B. <gb...@ki...> - 2009-10-28 00:38:05
|
Does CMake look in subdirectories of Modules automatically? If it does, this would also be a good solution. Otherwise, I vote for the prefix method as it is easier to use. Geoff Alex Brooks wrote: >> I think that we should mark our *.cmake somehow if we are dumping them >> into a common directory (e.g. /usr/local/cmake/Modules/ ). >> Putting something like Assert.cmake in common place is pretty rude. >> Should prepend Gbx to all of them? >> >> /usr/local/cmake/Modules/GbxAssert.cmake ??? > > I like having the gearbox ones easy to find. Another option would put them > into a subdir: > /usr/local/cmake/Modules/gearbox/Assert.cmake ??? |
From: Alex M. <al...@ca...> - 2009-10-28 13:06:55
|
After looking around I'm not sure why we want to move the current installation point at all. On the plus side, the current scheme works and the installed location is self-contained. I couldn't find any mention of /usr/local/cmake/Modules as the "standard" place for user files. And I found several open source projects which install exactly where we do. Rich, can you point me to a link which says that this is the preferred location? By the way, if someone is using the installed gearbox scripts and does not want to specify the absolute path they can edit the CMAKE_MODULE_PATH variable. On Wed, Oct 28, 2009 at 11:37 AM, Geoff Biggs <gb...@ki...> wrote: > Does CMake look in subdirectories of Modules automatically? If it does, > this would also be a good solution. Otherwise, I vote for the prefix > method as it is easier to use. > > Geoff > > Alex Brooks wrote: >>> I think that we should mark our *.cmake somehow if we are dumping them >>> into a common directory (e.g. /usr/local/cmake/Modules/ ). >>> Putting something like Assert.cmake in common place is pretty rude. >>> Should prepend Gbx to all of them? >>> >>> /usr/local/cmake/Modules/GbxAssert.cmake ??? >> >> I like having the gearbox ones easy to find. Another option would put them >> into a subdir: >> /usr/local/cmake/Modules/gearbox/Assert.cmake ??? > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Gearbox-devel mailing list > Gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearbox-devel > |
From: Rich M. <jp...@gm...> - 2009-10-28 14:25:23
|
Hi, I'm going to go ahead and reply to both emails here. ${prefix}/share/cmake/Modules is the fallback path for the find_package command: http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_package Within your build system, you can set CMAKE_MODULE_PATH wherever you want, and it will still fall back to this path when searching for packages (unless you explicitly tell it not to.) So it doesn't really matter where you put things, and might be better if you don't put anything in the default cmake module path unless you create a FindGearbox.cmake file. That might also make it easier for orca's buildsystem to find Gearbox. Putting the cmake files in ${prefix}/share/gearbox/cmake might be best. And for the other email: I submitted the patch to gearbox's sf patch tracker, but I think I'm going to want to change a few things after the above discourse. I'm going to revise the patch a bit and try to change the behavior of a few things back to the package default. As far as packaging things goes, there's 6 or 7 projects in Fedora that do add .cmake files in their own libdir directory, so I could probably get away with it. Some people expressed concern that ldd failed to resolve librar dependencies because ld couldn't find the libraries in the gearbox folder (for example: ldd /usr/lib/gearbox/libhokuyo_aist.so results in "libflexiport.so: not found"). Adding an entry to /etc/ld.so.conf.d/ should fix that. Rich -----Original Message----- From: Alex Makarenko [mailto:al...@ca...] Sent: Wednesday, October 28, 2009 9:07 AM To: gea...@li... Subject: Re: [Gearbox-devel] Packaging for Fedora After looking around I'm not sure why we want to move the current installation point at all. On the plus side, the current scheme works and the installed location is self-contained. I couldn't find any mention of /usr/local/cmake/Modules as the "standard" place for user files. And I found several open source projects which install exactly where we do. Rich, can you point me to a link which says that this is the preferred location? By the way, if someone is using the installed gearbox scripts and does not want to specify the absolute path they can edit the CMAKE_MODULE_PATH variable. On Wed, Oct 28, 2009 at 11:37 AM, Geoff Biggs <gb...@ki...> wrote: > Does CMake look in subdirectories of Modules automatically? If it does, > this would also be a good solution. Otherwise, I vote for the prefix > method as it is easier to use. > > Geoff > > Alex Brooks wrote: >>> I think that we should mark our *.cmake somehow if we are dumping them >>> into a common directory (e.g. /usr/local/cmake/Modules/ ). >>> Putting something like Assert.cmake in common place is pretty rude. >>> Should prepend Gbx to all of them? >>> >>> /usr/local/cmake/Modules/GbxAssert.cmake ??? >> >> I like having the gearbox ones easy to find. Another option would put them >> into a subdir: >> /usr/local/cmake/Modules/gearbox/Assert.cmake ??? > > ---------------------------------------------------------------------------- -- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Gearbox-devel mailing list > Gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearbox-devel > ---------------------------------------------------------------------------- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Gearbox-devel mailing list Gea...@li... https://lists.sourceforge.net/lists/listinfo/gearbox-devel |
From: Alex M. <al...@ca...> - 2009-11-06 07:19:23
|
Rich, > Putting the cmake files in ${prefix}/share/gearbox/cmake might be best. OK, we'll leave them where they are. > > And for the other email: I submitted the patch to gearbox's sf patch > tracker, but I think I'm going to want to change a few things after the > above discourse. I'm going to revise the patch a bit and try to change the > behavior of a few things back to the package default. I've applied half of your patch. I did the easy chages: 64bitness, bug fixes to the install path variables. the remaining has to do with PackageConfig gear, a bit harder to follow and verify. I didn't want to spend the time because you'd mentioned that you still want to do some changes. are you still planning to do it? one question on your version: it looks like your configure_file destination directory is in the source brach (not the binary branch): set( _input_dir ${PROJECT_SOURCE_DIR}/cmake/internal ) set( _output_dir ${PROJECT_SOURCE_DIR}/cmake/internal ) I think it would be better to put it on the binary side so that the out-of-source build does not add any files to the source tree. what do you think? I'd like to release soon. Anything else missing? cheers, alex |
From: Geoffrey B. <geo...@ai...> - 2009-11-06 07:25:06
|
Alex Makarenko wrote: > one question on your version: > it looks like your configure_file destination directory is in the > source brach (not the binary branch): > > set( _input_dir ${PROJECT_SOURCE_DIR}/cmake/internal ) > set( _output_dir ${PROJECT_SOURCE_DIR}/cmake/internal ) > > I think it would be better to put it on the binary side so that the > out-of-source build does not add any files to the source tree. > what do you think? Any generated files should absolutely always go in the binary directory. CMake is designed with this usage pattern in mind, and I think it's ideal to keep the source tree clean. With suitable paths set as needed there's no need to put stuff in the source directory. > I'd like to release soon. > Anything else missing? We should rename the cmake files that get installed first, then. Did we agree on which solution was best? Geoff |
From: Rich M. <jp...@gm...> - 2009-11-06 14:33:52
|
This is the part I wanted to take a look at again. Based on some of the lines that were commented out in WritePackageConfig, it looks like at one point the gearbox-config and gearbox-config-internal were autogenerated using cmake's configure. That changed in favor of including pre-generated files in the source tree, and getting rid of the .in files. This is problematic now, since now the library paths in both files can vary depending on a 32/64 bit build. If I can find where this changed in the subversion history, I will try revert it. Otherwise I'll figure it out. I overwrote the file in the source directory because cmake was already set up to install this copy. I see the problem with this now. It looks like gearbox-config.cmake and gearbox-config-internal.cmake should be replaced with .in files, and generated at build time like gearbox-config-version.cmake is. Rich -----Original Message----- From: Geoffrey Biggs [mailto:geo...@ai...] Sent: Friday, November 06, 2009 2:25 AM To: gea...@li... Subject: Re: [Gearbox-devel] Packaging for Fedora Alex Makarenko wrote: > one question on your version: > it looks like your configure_file destination directory is in the > source brach (not the binary branch): > > set( _input_dir ${PROJECT_SOURCE_DIR}/cmake/internal ) > set( _output_dir ${PROJECT_SOURCE_DIR}/cmake/internal ) > > I think it would be better to put it on the binary side so that the > out-of-source build does not add any files to the source tree. > what do you think? Any generated files should absolutely always go in the binary directory. CMake is designed with this usage pattern in mind, and I think it's ideal to keep the source tree clean. With suitable paths set as needed there's no need to put stuff in the source directory. > I'd like to release soon. > Anything else missing? We should rename the cmake files that get installed first, then. Did we agree on which solution was best? Geoff ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gearbox-devel mailing list Gea...@li... https://lists.sourceforge.net/lists/listinfo/gearbox-devel |
From: Alex M. <al...@ca...> - 2009-11-07 00:12:07
|
Rich, ok, I understand what needs to be done. I'll get it to take into account the 32/64 situation. It's probably easier for me to do it because I'd have to test it with dependent projects anyway. I'll do it this weekend and we should be good to go after that. Alex On Sat, Nov 7, 2009 at 1:33 AM, Rich Mattes <jp...@gm...> wrote: > This is the part I wanted to take a look at again. Based on some of the > lines that were commented out in WritePackageConfig, it looks like at one > point the gearbox-config and gearbox-config-internal were autogenerated > using cmake's configure. That changed in favor of including pre-generated > files in the source tree, and getting rid of the .in files. This is > problematic now, since now the library paths in both files can vary > depending on a 32/64 bit build. If I can find where this changed in the > subversion history, I will try revert it. Otherwise I'll figure it out. > > I overwrote the file in the source directory because cmake was already set > up to install this copy. I see the problem with this now. It looks like > gearbox-config.cmake and gearbox-config-internal.cmake should be replaced > with .in files, and generated at build time like > gearbox-config-version.cmake is. > > Rich > > > -----Original Message----- > From: Geoffrey Biggs [mailto:geo...@ai...] > Sent: Friday, November 06, 2009 2:25 AM > To: gea...@li... > Subject: Re: [Gearbox-devel] Packaging for Fedora > > Alex Makarenko wrote: >> one question on your version: >> it looks like your configure_file destination directory is in the >> source brach (not the binary branch): >> >> set( _input_dir ${PROJECT_SOURCE_DIR}/cmake/internal ) >> set( _output_dir ${PROJECT_SOURCE_DIR}/cmake/internal ) >> >> I think it would be better to put it on the binary side so that the >> out-of-source build does not add any files to the source tree. >> what do you think? > > Any generated files should absolutely always go in the binary directory. > CMake is designed with this usage pattern in mind, and I think it's > ideal to keep the source tree clean. With suitable paths set as needed > there's no need to put stuff in the source directory. > >> I'd like to release soon. >> Anything else missing? > > We should rename the cmake files that get installed first, then. Did we > agree on which solution was best? > > Geoff > > ---------------------------------------------------------------------------- > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gearbox-devel mailing list > Gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearbox-devel > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gearbox-devel mailing list > Gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearbox-devel > |
From: Alex M. <al...@ca...> - 2009-11-07 04:15:45
|
ok, I've gone through the cmake files and did a good cleanup of how the install directories are determined. the logic for this was distributed over multiple file, difficult to maintain. all of it is now in one place, cmake/SetupDirectories.cmake <CODE> set( GBX_BIN_INSTALL_SUFFIX bin ) set( GBX_INCLUDE_INSTALL_SUFFIX include/${PROJECT_NAME} ) set( GBX_SHARE_INSTALL_SUFFIX share/${PROJECT_NAME} ) set( GBX_CMAKE_INSTALL_SUFFIX ${GBX_SHARE_INSTALL_SUFFIX}/cmake ) if( GBX_PROC_64BIT ) set( GBX_LIB_INSTALL_SUFFIX lib64/${PROJECT_NAME} ) set( GBX_PKGCONFIG_INSTALL_SUFFIX lib64/pkgconfig ) else() set( GBX_LIB_INSTALL_SUFFIX lib/${PROJECT_NAME} ) set( GBX_PKGCONFIG_INSTALL_SUFFIX lib/pkgconfig ) endif() # by convention, we install cmake package-config files with the libraries set( GBX_CMAKE_PKGCONFIG_INSTALL_SUFFIX ${GBX_LIB_INSTALL_SUFFIX} ) </CODE> after this the actual absolute directories (e.g. GBX_BIN_INSTALL_DIR) are set by appending the *_SUFFIX to CMAKE_INSTALL_PREFIX. The package-config.cmake file is now properly configured using the variables above. The dashboard is green but please test on your local installations. The version is now 9.11.0 Rich, can you test for your specific packaging requirements. cheers, alex On Sat, Nov 7, 2009 at 11:11 AM, Alex Makarenko <al...@ca...> wrote: > Rich, > ok, I understand what needs to be done. > I'll get it to take into account the 32/64 situation. > It's probably easier for me to do it because I'd have to test it with > dependent projects anyway. > I'll do it this weekend and we should be good to go after that. > > Alex > > > On Sat, Nov 7, 2009 at 1:33 AM, Rich Mattes <jp...@gm...> wrote: >> This is the part I wanted to take a look at again. Based on some of the >> lines that were commented out in WritePackageConfig, it looks like at one >> point the gearbox-config and gearbox-config-internal were autogenerated >> using cmake's configure. That changed in favor of including pre-generated >> files in the source tree, and getting rid of the .in files. This is >> problematic now, since now the library paths in both files can vary >> depending on a 32/64 bit build. If I can find where this changed in the >> subversion history, I will try revert it. Otherwise I'll figure it out. >> >> I overwrote the file in the source directory because cmake was already set >> up to install this copy. I see the problem with this now. It looks like >> gearbox-config.cmake and gearbox-config-internal.cmake should be replaced >> with .in files, and generated at build time like >> gearbox-config-version.cmake is. >> >> Rich >> >> >> -----Original Message----- >> From: Geoffrey Biggs [mailto:geo...@ai...] >> Sent: Friday, November 06, 2009 2:25 AM >> To: gea...@li... >> Subject: Re: [Gearbox-devel] Packaging for Fedora >> >> Alex Makarenko wrote: >>> one question on your version: >>> it looks like your configure_file destination directory is in the >>> source brach (not the binary branch): >>> >>> set( _input_dir ${PROJECT_SOURCE_DIR}/cmake/internal ) >>> set( _output_dir ${PROJECT_SOURCE_DIR}/cmake/internal ) >>> >>> I think it would be better to put it on the binary side so that the >>> out-of-source build does not add any files to the source tree. >>> what do you think? >> >> Any generated files should absolutely always go in the binary directory. >> CMake is designed with this usage pattern in mind, and I think it's >> ideal to keep the source tree clean. With suitable paths set as needed >> there's no need to put stuff in the source directory. >> >>> I'd like to release soon. >>> Anything else missing? >> >> We should rename the cmake files that get installed first, then. Did we >> agree on which solution was best? >> >> Geoff >> >> ---------------------------------------------------------------------------- >> -- >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Gearbox-devel mailing list >> Gea...@li... >> https://lists.sourceforge.net/lists/listinfo/gearbox-devel >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Gearbox-devel mailing list >> Gea...@li... >> https://lists.sourceforge.net/lists/listinfo/gearbox-devel >> > |