[cmake-developers] Missing docs for CMAKE_FIND_PACKAGE_NAME and possible cmake code generation bug.

[David Cole]

On Mon, Oct 1, 2012 at 3:39 PM, Alexander Neundorf <neundorf at kde.org> wrote:

> On Monday 01 October 2012, Stephen Kelly wrote:
> > Hi,
> >
> > In commit 6f50a04cc1c4584472f850e06daad7ae20af45c4, a
> > CMAKE_FIND_PACKAGE_NAME variable was introduced, but not documented.
> > Sometimes it is deliberate to not document things like that, but I
> thought
> > I'd ask if it is.
>
> Until now it is used only internally, and I wanted to keep it internal
> until
> the code has seen some more testing.
>
> > The same commit generates cmake code with uppercasing, but with empty
> endif
> > commands.
> >
> > I think I saw that cmake code generated by cmake remains uppercase in
> case
> > anyone using an older cmake is processing files generated by a newer
> cmake.
>
> It's upper case simply because the surrounding code is also uppercase.
> Mixing upper- and lower case is support I think at least since 2.4.3.
>
> > Does the same apply to populating the end* commands?
>
> This is valid since quite some time too, maybe 2.6.0 ?
>
> > Such cases of old and new cmake are not unit tested obviously, but then
> if
> > we're not unit testing the case, can we expect to maintain it? Should we
> > maybe just lower case the generated code too as was done with all the
> other
> > cmake code?
>
> Hmm, are the generated files in general expected to require at least the
> cmake
> version they have been generated with ?
>
> Alex
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
>

I think in general, it's a reasonable expectation that generated code
should be allowed to use variables and features known to be in the very
latest version of CMake.

However, I also think it is wise to generate code that works with "as old a
CMake as practical" and not rely on things in the latest version.

If it's required to reference newer things, then do so. But avoid them if
possible as long as it doesn't lead to writing crazy code just to avoid the
dependence.

The problem, of course, is that it may not make sense to generate a
cmake_minimum_required in all these contexts, and so, there's not really a
good way to indicate an error sometime in these generated files.

If there are questions about specifics, obviously, let's discuss them...
but these are my thoughts on your question of expectations.


HTH,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20121001/8694ad3f/attachment.html>