Re: [cmake-developers] Specifying VS target platform
On Mon, 17 Sep 2012 09:57:28 -0400, Brad King wrote:
On 09/14/2012 05:59 PM, Patrick Gansterer wrote:
Maybe you can merge the first patch already.
Yes, done.
The idea of a generator platform is not generic among all
generators.
Rather than the general CMAKE_GENERATOR_PLATFORM infrastructure I'd
generator-specific handling. The value of -GP should be passed to
the
global generator created from -G. If the generator does not
support
platform specification in this way then -GP should be an error (all
generators except VS = 8). If the generator does support -GP then
it
should do its own thing to save the value. For VS save it in a
cache
entry like CMAKE_VS_PLATFORM (we have CMAKE_VS_PLATFORM_TOOLSET
already for the VS 10 toolchain in some cases).
I'm not a big fan of your ideas: What about the parts where we
pass the generator platform to other parts? Do we want to add
branches for every generator type to get get correct value for
the -GP parameter (e.g. if (CMAKE_GENERATOR == Visual Studio
...) -GP ${CMAKE_VS_PLATFORM})? IMHO that's not a good
idea. Also handling for making sure that generator platform
isn't changed by the user (like we do for -G already) in a
second run of CMake must be duplicated later if we add -GP to
more than one generator. (and so on...)
Good points, but we still need to reject -GP when using generators
for which it does not make sense. I think it may be moot anyway;
see below.
I realized that existing projects may test ${CMAKE_GENERATOR} to
look
for things like Win64. For compatibility we need to make sure
that
-G Visual Studio 10 -GP x64
results in CMAKE_GENERATOR being set to
-G Visual Studio 10 Win64
while processing CMake code even if it is not used that way
internally. Of course for future VS versions the generator names
will not need to work this way, only the existing ones.
Since we need to support -G Visual Studio 10 Win64 anyway, I don't
see
much problem if such cases will work with -G Visual Studio 10
Win64,
but not with -G Visual Studio 10 -GP x64.
We are talking about changing the way the user selects the generator
in the GUI to be equivalent to -G/-GP. We cannot process existing
projects differently depending on how the generator was selected.
I also know there are projects that pass ${CMAKE_GENERATOR} to
internal invocations of CMake in order to say build it like I'm
built. These paths would not work if any information moved over
to CMAKE_GENERATOR_PLATFORM or an equivalent variable.
I think the value of -GP has to be stored in CMAKE_GENERATOR at
the end of the generator name as it is now. The new option and GUI
updates are really just about simplifying the selection of the
generator and avoiding per-platform global generators in the internal
implementation. Users can either use -G and specify the full
generator name with platform or use -G/-GP separately but either way
the value of CMAKE_GENERATOR will be the same.
This can probably be improved in the future with a new cmake policy
but I don't want to open that can of worms just for WinCE. I think
you can implement -G/-GP such that the values are both stored in the
CMAKE_GENERATOR value. Internally we won't need a separate global
generator for every platform anymore, but that does not change the
public interface.
If we store everything in one variable (via string concatenation) I
don't see much value in an extra -GP switch. We need to split the
${CMAKE_GENERATOR} variable into generator+platform then all the time
anyway.
Maybe we can only change to current exact match of the generator name
to a startsWith and let the global generator class decide if the
generator name is valid?
-- Patrick
--
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
Re: [cmake-developers] Specifying VS target platform
On 09/18/2012 02:23 AM, Patrick Gansterer wrote:
If we store everything in one variable (via string concatenation) I
don't see much value in an extra -GP switch. We need to split the
${CMAKE_GENERATOR} variable into generator+platform then all the time
anyway.
Maybe we can only change to current exact match of the generator name
to a startsWith and let the global generator class decide if the
generator name is valid?
Yes, something like that in cmake::CreateGlobalGenerator will work.
It will be nice to get rid of the platform-varied generator classes.
The reference documentation we generate explicitly lists all names
with the platforms right now. That will have to be refactored to
list the platformless names with a note about where to specify the
platform name. Then we need a per-generator list of platform names
along with a note that one specifies Win32 by leaving the platform
name off.
Thanks,
-Brad
--
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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Monday 17 September 2012, Alexander Neundorf wrote: On Monday 17 September 2012, Alexander Neundorf wrote: On Monday 17 September 2012, Brad King wrote: On 09/15/2012 04:45 PM, Alexander Neundorf wrote: There is now a branch export-sets-2 on cmake stage. It cherry-picks a lot of the patches from http://gitorious.org/~urkud1/cmake/urkud-cmake/commits/w/export-set, mostly those from May, and then proceeds a bit differently. In the end, cmake now checks whether a target which is missing in the current export set has been exported and installed exactly once, gets the correct name from that one installation (i.e. the used namespace), and uses that. That simple approach will allow us to move forward with this. If anyone wants multiple exports of the same targets then they can add the explicit export set DEPENDS options later. Cool. The tests are not yet passing, I'll work on this. The tests are passing now. I had to change the order how the target files are included in the test, so that the required targets already exist when the other targets are set up. I pushed that to stage too. I think basically we're back to generating useful error messages again... How about defining a variable which can be set by Config-files which holds an error message for the case that the Config-file has set package_FOUND to FALSE ? Like e.g. package_FIND_FAILURE_MESSAGE ? This could then be printed by cmFindPackage and/or FPHSA ? 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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 09/18/2012 04:12 PM, Alexander Neundorf wrote: How about defining a variable which can be set by Config-files which holds an error message for the case that the Config-file has set package_FOUND to FALSE ? Like e.g. package_FIND_FAILURE_MESSAGE ? This could then be printed by cmFindPackage and/or FPHSA ? It sounds okay to me. -Brad -- 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
Re: [cmake-developers] Tests with custom launchers and Not Run
On 09/12/2012 11:23 PM, Mathias Gaunard wrote: On 12/09/2012 22:39, Mathias Gaunard wrote: I'd be content with just interpreting a return value of 77 as a Not Run status; this is a fairly trivial change that should work well in any existing setups. I don't think it is really needed to make things as complex as in the bug report. Any intelligence, if required, can go in the test command itself. Simple patch attached. This fulfills my needs well enough and I've just configured my cross-compilation test servers to use it. This is simple and works. Is it satisfying? Any chance of having it included? -- 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
Re: [cmake-developers] Tests with custom launchers and Not Run
I don't like it. Existing tests that run and return, for example, a number of errors that occurred, will magically appear as not run when that number just so happens to be 77. If there are enough people who think this is simple and works and are not concerned about the accidental matching of an intentional return value of 77 that does NOT mean not run ... then I will relent and say, so be it, and allow it in. But only if there are some people who speak up here or add notes to the bug. It just seems wrong to me to treat 77 as some special number here. On Tue, Sep 18, 2012 at 5:11 PM, Mathias Gaunard mathias.gaun...@ens-lyon.org wrote: On 09/12/2012 11:23 PM, Mathias Gaunard wrote: On 12/09/2012 22:39, Mathias Gaunard wrote: I'd be content with just interpreting a return value of 77 as a Not Run status; this is a fairly trivial change that should work well in any existing setups. I don't think it is really needed to make things as complex as in the bug report. Any intelligence, if required, can go in the test command itself. Simple patch attached. This fulfills my needs well enough and I've just configured my cross-compilation test servers to use it. This is simple and works. Is it satisfying? Any chance of having it included? -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- 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
Re: [cmake-developers] Tests with custom launchers and Not Run
On 09/18/2012 11:37 PM, David Cole wrote: I don't like it. Existing tests that run and return, for example, a number of errors that occurred, will magically appear as not run when that number just so happens to be 77. If there are enough people who think this is simple and works and are not concerned about the accidental matching of an intentional return value of 77 that does NOT mean not run ... then I will relent and say, so be it, and allow it in. But only if there are some people who speak up here or add notes to the bug. It just seems wrong to me to treat 77 as some special number here. Well, you need to interpret a return value as a special value to be able to tell executables could not be tested. Without this, a whole category status is entirely unusable to whoever wants to use custom launchers! That's a pretty serious issue to me. 77 already exists in the autotools world, so it seems like a good idea to re-use it. Making the executable return the number of failing tests is a very bad idea: it doesn't even scale beyond 255 for the average operating system. Certain operating systems also have funny behaviour with exit status as well: with OpenVMS, all even values are considered failures and all odd values are considered successes. -- 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
[cmake-developers] [CMake 0013548]: Updated cmake-mode.el
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13548 == Reported By:tschutter Assigned To: == Project:CMake Issue ID: 13548 Category: Documentation Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2012-09-18 23:57 EDT Last Modified: 2012-09-18 23:57 EDT == Summary:Updated cmake-mode.el Description: I have updated the cmake-mode.el file available at http://www.cmake.org/CMakeDocs/cmake-mode.el to include a keymap. This allows the user to define keys that only apply to cmake-mode. For example, you can now get help on a command by typing C-c h instead of C-x cmake-help-command. I have attached the updated cmake-mode.el == Issue History Date ModifiedUsername FieldChange == 2012-09-18 23:57 tschutter New Issue 2012-09-18 23:57 tschutter File Added: cmake-mode.el == -- 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
