From: Matt L. <mat...@gm...> - 2008-03-18 17:57:15
|
Dear VXL Developers, We at Brown have recently started using Expat as a 3rd party library in contrib/brl. We set it up in a similar way to the v3p libraries (i.e. it's in /contrib/brl/b3p). While it is currently limited to brl, we can easily move the files into v3p if anyone else wants to use it outside of brl. However, the errors we are seeing on the dashboard are independent of whether the code is in b3p or v3p, so I will discuss this general problem with respect to v3p. When checking to see if a v3p library is available natively, we use the FindX.cmake (X = EXPAT in this case) module that is packaged with CMake. If such a module is not available, we add one to vxl/config/cmake/Modules/NewCMake/ and use that instead. We then submit the module to Kitware for future inclusion in CMake. My question is: when do we stop supporting the old versions of CMake and start using the modules that now come with CMake? With respect to Expat, FindEXPAT.cmake is packaged with CMake versions 2.4 and up. However, there are some dashboard builds that are still using an older version of CMake without this file. Does that mean I should copy this file into the NewCMake directory? There are already plenty of files there that have long been included with CMake. When do we stop using these? Is there an official minimum version of CMake required for VXL? Thank, Matt |
From: Brad K. <bra...@ki...> - 2008-03-19 12:53:59
|
Matt Leotta wrote: > Dear VXL Developers, > > We at Brown have recently started using Expat as a 3rd party library > in contrib/brl. We set it up in a similar way to the v3p libraries > (i.e. it's in /contrib/brl/b3p). While it is currently limited to > brl, we can easily move the files into v3p if anyone else wants to use > it outside of brl. However, the errors we are seeing on the dashboard > are independent of whether the code is in b3p or v3p, so I will > discuss this general problem with respect to v3p. > > When checking to see if a v3p library is available natively, we use > the FindX.cmake (X = EXPAT in this case) module that is packaged with > CMake. If such a module is not available, we add one to > vxl/config/cmake/Modules/NewCMake/ and use that instead. We then > submit the module to Kitware for future inclusion in CMake. My > question is: when do we stop supporting the old versions of CMake and > start using the modules that now come with CMake? > > With respect to Expat, FindEXPAT.cmake is packaged with CMake > versions 2.4 and up. However, there are some dashboard builds that > are still using an older version of CMake without this file. Does > that mean I should copy this file into the NewCMake directory? There > are already plenty of files there that have long been included with > CMake. When do we stop using these? Is there an official minimum > version of CMake required for VXL? CMake 2.4 has been out for 2 years now. I think we should just bump up the version used for the dashboard builds and drop support for 2.2 and below. -Brad |
From: Amitha P. <ami...@us...> - 2008-03-19 15:26:37
|
I think if there is a CMake feature (including FindX modules) that we want to use from a CMake > 6 months old, we should send a message to maintainers suggesting the change to the required CMake. (This is more of a suggestion/opinion that is intended as a policy statement if no-one objects. I find that the lack of responses on this list sometimes means that questions and ideas need to be expressed as pseudo-policy statements. :-) ) Given this policy, we can move all the way up to CMake 2.4.7, but not yet to 2.4.8. Amitha. |
From: Matt L. <mat...@gm...> - 2008-03-19 15:50:39
|
Amitha, I think we do need a policy like this, but I'm worried that 6 months might be too aggressive. Several people (including myself) use a packaged version of CMake provided by the operating system (e.g. linux). These packaged versions are updated when a new stable release of the OS comes out. For Ubuntu this is every 6 months, but for Debian it can be more like a year or two. I like to avoid overriding my package management system whenever possible. FYI, stable Debian uses CMake 2.4.5. Maybe 12 months is a better timeframe? Either way, we certainly have several dashboard builds that could use a CMake update. Also, given such a policy, is it time to start cleaning out the NewCMake directory? Thanks, Matt On Wed, Mar 19, 2008 at 11:26 AM, Amitha Perera <ami...@us...> wrote: > I think if there is a CMake feature (including FindX modules) that we > want to use from a CMake > 6 months old, we should send a message to > maintainers suggesting the change to the required CMake. > > (This is more of a suggestion/opinion that is intended as a policy > statement if no-one objects. I find that the lack of responses on this > list sometimes means that questions and ideas need to be expressed as > pseudo-policy statements. :-) ) > > Given this policy, we can move all the way up to CMake 2.4.7, but not > yet to 2.4.8. > > Amitha. > |
From: Amitha P. <ami...@us...> - 2008-03-19 19:03:04
|
Matt Leotta wrote: > I think we do need a policy like this, but I'm worried that 6 months > might be too aggressive.[...] Fair enough. Perhaps we can go with a "reasonable" update. For example, you know that the modules in, e.g., 2.4.3 are good, and we should use it. 2.4.3 is not brand new. Send out a message to maintainers, state the value add, and we can quickly debate it. I think it'd be better to force reasonable CMake upgrades than keep populating Modules/NewCMake. As you wrote, maybe "reasonable" should be based on the latest available on a bunch of common platforms. > Either way, > we certainly have several dashboard builds that could use a CMake > update. Folks that maintain a dashboard build: it there any reason not to use CMake >= 2.4.5? > Also, given such a policy, is it time to start cleaning out the > NewCMake directory? I think we should certainly clean out NewCMake to match the minimum CMake version that we agree on. Amitha. |
From: Matt L. <mat...@gm...> - 2008-03-19 19:19:30
|
I'd say 2.4.5 is reasonable. My vote is for this to be the minimum CMake version supported by VXL (for now). The only builds with an older version are the FreeBSD builds at RPI. These are also the only builds with the Expat problem. They are documented as being maintained by Jacob Becker and Michal Sofka. Would you guys be willing to update CMake? --Matt On Wed, Mar 19, 2008 at 3:03 PM, Amitha Perera <ami...@us...> wrote: > Matt Leotta wrote: > > I think we do need a policy like this, but I'm worried that 6 months > > might be too aggressive.[...] > > Fair enough. Perhaps we can go with a "reasonable" update. For > example, you know that the modules in, e.g., 2.4.3 are good, and we > should use it. 2.4.3 is not brand new. Send out a message to > maintainers, state the value add, and we can quickly debate it. > > I think it'd be better to force reasonable CMake upgrades than keep > populating Modules/NewCMake. As you wrote, maybe "reasonable" should be > based on the latest available on a bunch of common platforms. > > > > Either way, > > we certainly have several dashboard builds that could use a CMake > > update. > > Folks that maintain a dashboard build: it there any reason not to use > CMake >= 2.4.5? > > > > Also, given such a policy, is it time to start cleaning out the > > NewCMake directory? > > I think we should certainly clean out NewCMake to match the minimum > CMake version that we agree on. > > Amitha. > |
From: Michal S. <so...@cs...> - 2008-03-19 21:47:57
|
> I'd say 2.4.5 is reasonable. My vote is for this to be the minimum > CMake version supported by VXL (for now). > > The only builds with an older version are the FreeBSD builds at RPI. > These are also the only builds with the Expat problem. They are > documented as being maintained by Jacob Becker and Michal Sofka. > Would you guys be willing to update CMake? Yes, Jacob promised to take care of this update. Michal. |
From: Ian S. <ian...@gm...> - 2008-03-20 09:18:35
|
I think 2.4.5 should be fine by Imorphics. Ian. Amitha Perera wrote: > Matt Leotta wrote: >> I think we do need a policy like this, but I'm worried that 6 months >> might be too aggressive.[...] > > Fair enough. Perhaps we can go with a "reasonable" update. For > example, you know that the modules in, e.g., 2.4.3 are good, and we > should use it. 2.4.3 is not brand new. Send out a message to > maintainers, state the value add, and we can quickly debate it. > > I think it'd be better to force reasonable CMake upgrades than keep > populating Modules/NewCMake. As you wrote, maybe "reasonable" should be > based on the latest available on a bunch of common platforms. > > > Either way, >> we certainly have several dashboard builds that could use a CMake >> update. > > Folks that maintain a dashboard build: it there any reason not to use > CMake >= 2.4.5? > >> Also, given such a policy, is it time to start cleaning out the >> NewCMake directory? > > I think we should certainly clean out NewCMake to match the minimum > CMake version that we agree on. > > Amitha. |
From: Brad K. <bra...@ki...> - 2008-04-10 13:55:16
|
Hi Folks, So it looks like all the dashboard submitters have upgraded to 2.4.5 or higher. It should now be safe to change to using CMAKE_MINIMUM_REQUIRED(VERSION 2.4.5) in the vxl source tree. If I hear no objections I plan to bump the requirement tomorrow morning (Friday, April 11 2008). -Brad |
From: Wheeler, F. W (G. Research) <wh...@cr...> - 2008-03-19 19:18:09
|
I think all my builds already use a cmake more recent than 2.4.5, so no problem with me. -----Original Message----- From: vxl...@li... [mailto:vxl...@li...] On Behalf Of Amitha Perera Sent: Wednesday, March 19, 2008 3:03 PM To: Matt Leotta Cc: Gamze Tunali; Vxl-maintainers Subject: Re: [Vxl-maintainers] How long do we support old versions of CMake? Matt Leotta wrote: > I think we do need a policy like this, but I'm worried that 6 months > might be too aggressive.[...] Fair enough. Perhaps we can go with a "reasonable" update. For example, you know that the modules in, e.g., 2.4.3 are good, and we should use it. 2.4.3 is not brand new. Send out a message to maintainers, state the value add, and we can quickly debate it. I think it'd be better to force reasonable CMake upgrades than keep populating Modules/NewCMake. As you wrote, maybe "reasonable" should be based on the latest available on a bunch of common platforms. > Either way, > we certainly have several dashboard builds that could use a CMake > update. Folks that maintain a dashboard build: it there any reason not to use CMake >= 2.4.5? > Also, given such a policy, is it time to start cleaning out the > NewCMake directory? I think we should certainly clean out NewCMake to match the minimum CMake version that we agree on. Amitha. ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Matt L. <mat...@gm...> - 2008-03-20 12:37:26
|
Fred, It seems that I missed one of the builds with old CMake. Your MinGW build is reporting CMake 2.0.3. Is that right? Can it be upgraded easily? Thanks, Matt On Wed, Mar 19, 2008 at 3:18 PM, Wheeler, Frederick W (GE, Research) <wh...@cr...> wrote: > > I think all my builds already use a cmake more recent than 2.4.5, so no > problem with me. > > > > -----Original Message----- > From: vxl...@li... > [mailto:vxl...@li...] On Behalf Of > Amitha Perera > Sent: Wednesday, March 19, 2008 3:03 PM > To: Matt Leotta > Cc: Gamze Tunali; Vxl-maintainers > Subject: Re: [Vxl-maintainers] How long do we support old versions of > CMake? > > Matt Leotta wrote: > > I think we do need a policy like this, but I'm worried that 6 months > > > might be too aggressive.[...] > > Fair enough. Perhaps we can go with a "reasonable" update. For > example, you know that the modules in, e.g., 2.4.3 are good, and we > should use it. 2.4.3 is not brand new. Send out a message to > maintainers, state the value add, and we can quickly debate it. > > I think it'd be better to force reasonable CMake upgrades than keep > populating Modules/NewCMake. As you wrote, maybe "reasonable" should be > based on the latest available on a bunch of common platforms. > > > Either way, > > we certainly have several dashboard builds that could use a CMake > > update. > > Folks that maintain a dashboard build: it there any reason not to use > CMake >= 2.4.5? > > > Also, given such a policy, is it time to start cleaning out the > > NewCMake directory? > > I think we should certainly clean out NewCMake to match the minimum > CMake version that we agree on. > > Amitha. > > ------------------------------------------------------------------------ > - > This SF.net email is sponsored by: Microsoft Defy all challenges. > Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Wheeler, F. W (G. Research) <wh...@cr...> - 2008-03-20 12:41:32
|
Matt, I just noticed that old cmake version this morning myself. I've already upgraded cmake on that machine. We should see the effect on tommorow's build. Fred -----Original Message----- From: Matt Leotta [mailto:mat...@gm...] Sent: Thursday, March 20, 2008 8:37 AM To: Wheeler, Frederick W (GE, Research) Cc: Vxl-maintainers Subject: Re: [Vxl-maintainers] How long do we support old versions of CMake? Fred, It seems that I missed one of the builds with old CMake. Your MinGW build is reporting CMake 2.0.3. Is that right? Can it be upgraded easily? Thanks, Matt On Wed, Mar 19, 2008 at 3:18 PM, Wheeler, Frederick W (GE, Research) <wh...@cr...> wrote: > > I think all my builds already use a cmake more recent than 2.4.5, so > no problem with me. > > > > -----Original Message----- > From: vxl...@li... > [mailto:vxl...@li...] On Behalf Of > Amitha Perera > Sent: Wednesday, March 19, 2008 3:03 PM > To: Matt Leotta > Cc: Gamze Tunali; Vxl-maintainers > Subject: Re: [Vxl-maintainers] How long do we support old versions of > CMake? > > Matt Leotta wrote: > > I think we do need a policy like this, but I'm worried that 6 months > > > might be too aggressive.[...] > > Fair enough. Perhaps we can go with a "reasonable" update. For > example, you know that the modules in, e.g., 2.4.3 are good, and we > should use it. 2.4.3 is not brand new. Send out a message to > maintainers, state the value add, and we can quickly debate it. > > I think it'd be better to force reasonable CMake upgrades than keep > populating Modules/NewCMake. As you wrote, maybe "reasonable" should > be based on the latest available on a bunch of common platforms. > > > Either way, > > we certainly have several dashboard builds that could use a CMake > > update. > > Folks that maintain a dashboard build: it there any reason not to use > CMake >= 2.4.5? > > > Also, given such a policy, is it time to start cleaning out the > > NewCMake directory? > > I think we should certainly clean out NewCMake to match the minimum > CMake version that we agree on. > > Amitha. > > > ---------------------------------------------------------------------- > -- > - > This SF.net email is sponsored by: Microsoft Defy all challenges. > Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > ---------------------------------------------------------------------- > --- This SF.net email is sponsored by: Microsoft Defy all > challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |