Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On 8/5/2011 5:14 PM, Alexander Neundorf wrote: (2) The documentation of the module has a few typos. Please proofread it again. Also, please use the word "compatible" rather than "suitable" to refer version acceptability. This makes the distinction noted above in (1). I hope it's better now. But I didn't merge it yet to next. The use of unsuitable in the implementation looks good, but see below. (3) After noting the implementation detail with configure_file the documentation should state that users should never directly configure the files themselves. Done. I don't see any commits on the WriteConfigVersionFile_2TemplateFiles topic that make changes to the main module file. Where did you put the new documentation changes? Thanks, -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On 8/3/2011 4:04 PM, Brad King wrote: On 8/3/2011 4:00 PM, Alexander Neundorf wrote: Are you ok with this branch or are there issues left (...since it wasn't merged into master on Tuesday) ? I still need to find time to do further review and try it out. Okay, here are a few comments from a quick review. (1) The pointer size sanity check should report failure with "PACKAGE_VERSION_UNSUITABLE" as documented here: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package http://www.cmake.org/Wiki/CMake/Tutorials/Packaging#Package_Version_Files The version might be compatible but the package is unsuitable anyway. With this approach you don't need to have the whole version check inside an else() block so the code should look simpler. (2) The documentation of the module has a few typos. Please proofread it again. Also, please use the word "compatible" rather than "suitable" to refer version acceptability. This makes the distinction noted above in (1). (3) After noting the implementation detail with configure_file the documentation should state that users should never directly configure the files themselves. (4) I wonder if we should just make AnyNewerVersion the default for COMPATIBILITY so it does not have to be specified at all in the most obvious and (probably) common case. Comments? Thanks, -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On 8/3/2011 4:00 PM, Alexander Neundorf wrote: Are you ok with this branch or are there issues left (...since it wasn't merged into master on Tuesday) ? I still need to find time to do further review and try it out. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On Monday 01 August 2011, Alexander Neundorf wrote: > On Monday 01 August 2011, Brad King wrote: > > On 07/31/2011 04:09 PM, Alexander Neundorf wrote: > > > I'm not sure which syntax I like better. The one with the macro feels > > > more high-level, but maybe hides too much what is actually going on > > > (which is not much). The one where the user must use configure_file() > > > directly feels more low-level, but doesn't try to make a secret of > > > what's going on, which may be better to encourage users to write their > > > own version files. > > > > > > Which one would you prefer ? > > > I'll add tests for the one we decide to use. > > > > I like the macro better. It will allow us to extend the capabilities > > later while retaining compatibility. If we let people configure the > > file directly then if we add more fields that need replacement in the > > future then old versions may stop working because there are no defaults > > for new fields. > > I pushed and merged now a 3rd branch > "WriteConfigVersionFile_2TemplateFiles" which does both: it provides the Are you ok with this branch or are there issues left (...since it wasn't merged into master on Tuesday) ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On Monday 01 August 2011, Brad King wrote: > On 07/31/2011 04:09 PM, Alexander Neundorf wrote: > > I'm not sure which syntax I like better. The one with the macro feels > > more high-level, but maybe hides too much what is actually going on > > (which is not much). The one where the user must use configure_file() > > directly feels more low-level, but doesn't try to make a secret of > > what's going on, which may be better to encourage users to write their > > own version files. > > > > Which one would you prefer ? > > I'll add tests for the one we decide to use. > > I like the macro better. It will allow us to extend the capabilities later > while retaining compatibility. If we let people configure the file > directly then if we add more fields that need replacement in the future > then old versions may stop working because there are no defaults for new > fields. I pushed and merged now a 3rd branch "WriteConfigVersionFile_2TemplateFiles" which does both: it provides the macro, and the macro uses one of the two template files (which are also mentioned in the documentation). So these template files stay simple and can easily be used as starting point for more sophisticated ones. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On 07/31/2011 04:09 PM, Alexander Neundorf wrote: > I'm not sure which syntax I like better. The one with the macro feels more > high-level, but maybe hides too much what is actually going on (which is not > much). The one where the user must use configure_file() directly feels more > low-level, but doesn't try to make a secret of what's going on, which may be > better to encourage users to write their own version files. > > Which one would you prefer ? > I'll add tests for the one we decide to use. I like the macro better. It will allow us to extend the capabilities later while retaining compatibility. If we let people configure the file directly then if we add more fields that need replacement in the future then old versions may stop working because there are no defaults for new fields. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On Sunday 31 July 2011, Brad King wrote:
> On 7/30/2011 3:33 AM, Rolf Eike Beer wrote:
> >> Another common scheme is to say that a version is compatible if the
> >> major version number matches and incompatible otherwise. I'm not
> >> saying we have to try to include every common scheme. I think just
> >> the basic one you proposed originally is sufficient. However, I'd
> >> like to come up with a name for it that will distinguish it from
> >> other schemes added in the future. Any ideas for a name?
> >
> > NewerVersionMatches and MajorVersionMatches?
>
> Those sound good, thanks!
Didn't know what the best way to do it would be, so there are now two branches
on stage, WriteConfigVersionFile and ConfigVersionFile_2Templates.
Both have the same purpose, but one provides a macro, which wraps the
configure_file() file call, and the other one provides two
ConfigVersion.cmake.in files, which the user can then use as input for
configure_file().
Usage with the macro is like this:
include(WriteBasicConfigVersionFile)
write_basic_config_version_file(${CMAKE_CURRENT_BINARY_DIR}/XyzConfigVersion.cmake
VERSION 2.3.4 COMPATIBILITY SameMajorVersion )
Alternatively "AnyNewerVersion" can be used instead of "SameMajorVersion".
With the two input files usage is like this:
set(PROJECT_VERSION 1.2.3)
configure_file(
${CMAKE_ROOT}/Modules/BasicConfigVersion-SameMajorVersion.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/XyzConfigVersion.cmake @ONLY )
Also here, alternatively BasicConfigVersion-AnyNewerVersion.cmake.in can be
used as input file.
And then in both cases:
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/XyzConfigVersion.cmake
${CMAKE_SOURCE_DIR}/XyzConfig.cmake
DESTINATION lib/cmake/xyz )
I'm not sure which syntax I like better. The one with the macro feels more
high-level, but maybe hides too much what is actually going on (which is not
much). The one where the user must use configure_file() directly feels more
low-level, but doesn't try to make a secret of what's going on, which may be
better to encourage users to write their own version files.
Which one would you prefer ?
I'll add tests for the one we decide to use.
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On 7/30/2011 3:33 AM, Rolf Eike Beer wrote: >> Another common scheme is to say that a version is compatible if the >> major version number matches and incompatible otherwise. I'm not >> saying we have to try to include every common scheme. I think just >> the basic one you proposed originally is sufficient. However, I'd >> like to come up with a name for it that will distinguish it from >> other schemes added in the future. Any ideas for a name? > > NewerVersionMatches and MajorVersionMatches? Those sound good, thanks! -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
> Another common scheme is to say that a version is compatible if the > major version number matches and incompatible otherwise. I'm not > saying we have to try to include every common scheme. I think just > the basic one you proposed originally is sufficient. However, I'd > like to come up with a name for it that will distinguish it from > other schemes added in the future. Any ideas for a name? NewerVersionMatches and MajorVersionMatches? Eike ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On 07/29/2011 12:04 PM, Alexander Neundorf wrote: > On Thursday 07 July 2011, Alexander Neundorf wrote: >> I think everything else are special cases, at least I can't think of other >> generic cases. >> How could another common scheme look like ? > > Any ideas ? Huh. I thought I responded to this one already but now I can't find it. Another common scheme is to say that a version is compatible if the major version number matches and incompatible otherwise. I'm not saying we have to try to include every common scheme. I think just the basic one you proposed originally is sufficient. However, I'd like to come up with a name for it that will distinguish it from other schemes added in the future. Any ideas for a name? > Beside that, attached is a modified version which now also fails if > SIZEOF_VOID_P of the installed version differs from the current on. Nice. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On Thursday 07 July 2011, Alexander Neundorf wrote:
> On Thursday 07 July 2011, Brad King wrote:
> > On 7/6/2011 4:00 PM, Alexander Neundorf wrote:
> > > Since that Version.cmake file in most cases looks basically the same
> >
> > They're only the same within a specific community's versioning scheme.
> > The whole reason find_package loads package-provided version check
> > files is to avoid imposing a versioning/compatibility scheme. If
> > we provide a template then we should name it after the scheme it
> > follows.
> >
> > Provide a module with macros to generate version files with different
> > common schemes. Use configure_file with CMakeConfigurableFile.in as
> > the input if you don't want a custom .in file.
>
> I'd do that, but when I first wrote that file, I was actually surprised
> that I could think of only one way to do it:
>
> if (currentVersion < requestedVersion)
> {
> compatible = false;
> }
> else
> {
> compatible = true;
> if (currentVersion == requestedVersion)
> {
> exact = true;
> }
> }
>
>
> I think everything else are special cases, at least I can't think of other
> generic cases.
> How could another common scheme look like ?
Any ideas ?
Beside that, attached is a modified version which now also fails if
SIZEOF_VOID_P of the installed version differs from the current on.
Alex
# This is a very basic file for the new style find_package() search mode,
# i.e. Config-mode.
# In this mode find_package() searches for a Config.cmake
# file and an associated Version.cmake file, which it loads to check
# the version number.
# This file can be used with configure_file() to generate such a file for a
project
# with very basic logic.
# It sets PACKAGE_VERSION_EXACT if the current version string and the requested
# version string are exactly the same and it sets PACKAGE_VERSION_COMPATIBLE
# if the current version is >= requested version.
# If this is not good enough for your project, you need to write your own
# improved Version.cmake file.
set(PACKAGE_VERSION @BAR_VERSION_MAJOR@.@BAR_VERSION_MINOR@.@BAR_VERSION_PATCH@)
if(NOT "@CMAKE_SIZEOF_VOID_P@" STREQUAL "${CMAKE_SIZEOF_VOID_P}")
math(EXPR installedBits "@CMAKE_SIZEOF_VOID_P@ * 8")
set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
set(PACKAGE_VERSION_COMPATIBLE FALSE)
# return()
#endif()
else()
if("${PACKAGE_VERSION}" VERSION_LESS "${PACKAGE_FIND_VERSION}" )
set(PACKAGE_VERSION_COMPATIBLE FALSE)
else("${PACKAGE_VERSION}" VERSION_LESS "${PACKAGE_FIND_VERSION}" )
set(PACKAGE_VERSION_COMPATIBLE TRUE)
if( "${PACKAGE_FIND_VERSION}" STREQUAL "${PACKAGE_VERSION}")
set(PACKAGE_VERSION_EXACT TRUE)
endif( "${PACKAGE_FIND_VERSION}" STREQUAL "${PACKAGE_VERSION}")
endif("${PACKAGE_VERSION}" VERSION_LESS "${PACKAGE_FIND_VERSION}" )
endif()___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On Thursday 07 July 2011, Brad King wrote:
> On 7/6/2011 4:00 PM, Alexander Neundorf wrote:
> > Since that Version.cmake file in most cases looks basically the same
>
> They're only the same within a specific community's versioning scheme.
> The whole reason find_package loads package-provided version check
> files is to avoid imposing a versioning/compatibility scheme. If
> we provide a template then we should name it after the scheme it
> follows.
>
> Provide a module with macros to generate version files with different
> common schemes. Use configure_file with CMakeConfigurableFile.in as
> the input if you don't want a custom .in file.
I'd do that, but when I first wrote that file, I was actually surprised that I
could think of only one way to do it:
if (currentVersion < requestedVersion)
{
compatible = false;
}
else
{
compatible = true;
if (currentVersion == requestedVersion)
{
exact = true;
}
}
I think everything else are special cases, at least I can't think of other
generic cases.
How could another common scheme look like ?
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
On 7/6/2011 4:00 PM, Alexander Neundorf wrote: > Since that Version.cmake file in most cases looks basically the same They're only the same within a specific community's versioning scheme. The whole reason find_package loads package-provided version check files is to avoid imposing a versioning/compatibility scheme. If we provide a template then we should name it after the scheme it follows. Provide a module with macros to generate version files with different common schemes. Use configure_file with CMakeConfigurableFile.in as the input if you don't want a custom .in file. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Adding MacroWriteBasicCMakeVersionFile.cmake file to cmake ?
Hi, in KDE we have a simple macro which helps with creating a FooConfigVersion.cmake for installation along the FooConfig.cmake file. Since that Version.cmake file in most cases looks basically the same, I thought it is a good idea to provide such a basic file, and the only thing which has to be changed there are the actual version numbers. This is this file: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/cmake/modules/BasicFindPackageVersion.cmake.in Additionally there is a small helper macro which takes the three version number components and does the configure_file(): https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/cmake/modules/MacroWriteBasicCMakeVersionFile.cmake so the user can then add the install(FILES ... ) command after that. IMO this is generic enough to be added to cmake. How ? As a combination of macro and cmake.in file as it is ? Or just the cmake.in file and let the users find out how to use that file themselves ? The problem with this is that the man page will not contain documentation about the cmake.in file, while it will contain documentation about the macro (if it is added as macro). Or only add the macro, and do file(WRITE ...) instead of configure_file() in it ? About the name: when added to cmake, I would probably simply strip the "Macro" prefix from it. Comments ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
