Re: [cmake-developers] Perforce Patch for CTest

[Rolf Eike Beer]

Am Montag, 21. Oktober 2013, 17:56:36 schrieb Pedro Navarro:
> Attached is the latest version of the Perforce support patch for CTest.
> I've added a test (CTest.UpdateP4) that launches a Perforce server
> listening on a custom port and performs the same operations as other VCS
> tools. Some release notes:
> 
>- Unix is expected. Windows could work (it's a matter of changing how
>the Perforce service is started) but I have no Windows machines handy to
>add support for it.
>- The Perforce p4 and p4d utilities must be installed. find_program()
>will be used to locate them
>- p4d will be started and a new database will be created at the
>beginning of each test run, so we will always test against a fresh and
> new repository.
>- Based on the tests, I modified how the P4 CTest client reports its
>modified paths, so now relative paths to the root are returned (without
> the depot name).
>- As I had a server (p4d) I was able to play succesfully with message
>localization so now I set the messages language to English before each
>command is executed, preventing problems with the results parsing if
>somebody ever configures Perforce in another language.
>- Fixed little cosmetic things here and there as a result of having it
>running in house for a couple of weeks.

I would extend the regex in the DiffParser constructor to contain " - " at the 
end to make the propability that a filename with # in it would cause issues 
smaller. Also I find the usage of both Options and options in SetP4Options() an 
invitation for confusion (and possible errors).

Also I see a possible conflict between LoadRevisions() and NoteOldRevision(). 
The latter sets OldRevision to "0" in case it can't load any, the former tests 
the variable for being empty. Given the right order of events this could 
result in different results.

get_filename_component(TOP "${CMAKE_CURRENT_LIST_FILE}" PATH) could be written 
as CMAKE_CURRENT_LIST_DIR. I don't remember exactly when it was introduced, 
but you drive that test with the newly built CMake so this must work. And a 
newline is missing at the end of that file.

Otherwise, awesome work.

Eike

signature.asc
Description: This is a digitally signed message part.
--

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] Perforce Patch for CTest

[Pedro Navarro]

Attached is the latest version of the Perforce support patch for CTest.
I've added a test (CTest.UpdateP4) that launches a Perforce server
listening on a custom port and performs the same operations as other VCS
tools. Some release notes:

   - Unix is expected. Windows could work (it's a matter of changing how
   the Perforce service is started) but I have no Windows machines handy to
   add support for it.
   - The Perforce p4 and p4d utilities must be installed. find_program()
   will be used to locate them
   - p4d will be started and a new database will be created at the
   beginning of each test run, so we will always test against a fresh and new
   repository.
   - Based on the tests, I modified how the P4 CTest client reports its
   modified paths, so now relative paths to the root are returned (without the
   depot name).
   - As I had a server (p4d) I was able to play succesfully with message
   localization so now I set the messages language to English before each
   command is executed, preventing problems with the results parsing if
   somebody ever configures Perforce in another language.
   - Fixed little cosmetic things here and there as a result of having it
   running in house for a couple of weeks.

Pedro


On Wed, Oct 16, 2013 at 1:10 PM, Brad King  wrote:

> On 10/16/2013 03:11 PM, Pedro Navarro wrote:
> > I was thinking that as the test requires the p4 tool to be installed,
> > we might as well require also p4d (the server, which is now free for
> > up to 20 users). In that case the test can bring up a local server
> > and work against it which, in the end, will create less issues as
> > the p4 database will be deleted when the test ends. If we work against
> > a real production server we might not be able to use p4 obliterate
> > and we will be leaving those temporary checkins the test does
> > polluting the history, and that might not be desired.
>
> We definitely need the test to run against a fresh repository each
> time.  The other VCS tool tests all create local repos from scratch
> when they run.  Whatever you need to require to achieve this with
> P4 is acceptable.
>
> Thanks,
> -Brad
>


0001-Perforce-support-for-CTest.patch
Description: Binary data
--

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] Patches for Visual Studio multi-CPU architecture project generation and a Windows-Phone-8 generator

[Patrick Gansterer]

Do Windows Store and Desktop apps have different toolsets? If yes it should be 
enough IMO.

On 21.10.2013, at 14:26, Paul Annetts wrote:

> To differentiate between Windows Store and Windows desktop apps. 
> 
> Paul.
> From: Patrick Gansterer
> Sent: ‎21/‎10/‎2013 09:12
> To: Paul Annetts
> Cc: 'Brad King'; cmake-developers@cmake.org
> Subject: Re: [cmake-developers] Patches for Visual Studio multi-CPU 
> architecture project generation and a Windows-Phone-8 generator
> 
> 
> On 21.10.2013, at 10:08, Paul Annetts wrote:
> > Patrick's comments about using CMAKE_GENERATOR_TOOLSET have made me think 
> > we should have a combined "Visual Studio 11 2012 Windows-Store" generator 
> > using CMAKE_GENERATOR_TOOLSET to switch between Windows Store and Windows 
> > Phone. 
> > (The Windows Store and Phone C/C++ APIs are very similar, but don't share 
> > an ABI).
> 
> Why do you need the special "Windows-Store" generator then?
> 
> -- 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] CTest: Request review of topic "ctest-fix-run-serial"

[Bill Hoffman]

On 10/21/2013 2:39 PM, Nils Gladitz wrote:

I haven't see that fail on my local test runs.
Is it sporadic or does it fail for you consistently?

Never mind on this one.  Looks like it fails for me without your changes.

-Bill

--

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] Cross compiling toolchain variables

[Stephen Kelly]

Hi,

I've pushed the cross-compiling-toolchain-variables topic to my clone. It is 
the merger of several topics which were discussed during the CMake 2.8.12 
feature cycle regarding CMAKE_SYSROOT etc.

I have reviewed how the features interact with try_compile and fixed that up 
as described here:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7705

I have also addressed the issue from this thread:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7698

My QNX toolchain file is now very simple:
 
 set(CMAKE_SYSTEM_NAME QNX)
 # The --sysroot flag is not supported by qcc,
 # set(CMAKE_SYSROOT /home/stephen/bbndk/target_10_1_0_1020/qnx6)
 set(CMAKE_FIND_ROOT_PATH
   /home/stephen/dev/build/qtbase-bb/qtbase-bb
   /home/stephen/bbndk/target_10_1_0_1020/qnx6
   /home/stephen/bbndk/target_10_1_0_1020/qnx6/armle-v7
 )

 set(CMAKE_C_COMPILER 
/home/stephen/bbndk/host_10_1_0_132/linux/x86/usr/bin/qcc)
 set(CMAKE_C_COMPILER_TARGET gcc_ntoarmv7le)
 set(CMAKE_CXX_COMPILER 
/home/stephen/bbndk/host_10_1_0_132/linux/x86/usr/bin/QCC)
 set(CMAKE_CXX_COMPILER_TARGET gcc_ntoarmv7le_cpp)

 set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
 set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
 set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
 set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)


compared to what is used in the wild currently:

 https://trac.lcsr.jhu.edu/cisst/attachment/wiki/qnx/Toolchain-QNX-6.4.1.cmake

My clang toolchain file for the raspberryPi is also very simple:

 
 set(CMAKE_SYSTEM_NAME Linux)

 set(CMAKE_SYSROOT /home/stephen/rpi/rasp-pi-rootfs)
 # Installation location of Qt 5
 set(CMAKE_FIND_ROOT_PATH /home/stephen/dev/src/qtbase-rpi/extprefix) 

 set(triple arm-linux-gnueabihf)
 set(gcc_toolchain /home/stephen/rpi/gcc-4.7-linaro-rpi-gnueabihf)

 set(CMAKE_C_COMPILER
   /home/stephen/dev/build/qtbase/llvm/bin/clang
 #   /home/stephen/dev/src/playground/cmake/arm-linux-gnueabihf-clang
 )
 set(CMAKE_C_COMPILER_TARGET ${triple})
 set(CMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN ${gcc_toolchain})
 set(CMAKE_CXX_COMPILER
   /home/stephen/dev/build/qtbase/llvm/bin/clang++
 #   /home/stephen/dev/src/playground/cmake/arm-linux-gnueabihf-clang++
 )
 set(CMAKE_CXX_COMPILER_TARGET ${triple})
 set(CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN ${gcc_toolchain})

 # Debian bug 708744
 include_directories(SYSTEM "${CMAKE_SYSROOT}/usr/include/${triple}")

 set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
 set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
 set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
 set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)


I have tested both toolchains with simple helloworld applications, a simple 
executable which depends on zlib, and with gammaray with Qt 5, with both 
Ninja and Unix Makefiles.

I have not worked on merging the CMAKE_OSX_SYSROOT feature with 
CMAKE_SYSROOT as I don't have the required OSX knowledge
 
 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7294/focus=7376

That also relates to this bug:

 https://bugreports.qt-project.org/browse/QTBUG-32308

and this mail:

 http://thread.gmane.org/gmane.comp.lib.qt.devel/13444/focus=13450

though I think the suggestion in that mail is incorrect. If anything is 
needed there at all, then it can't be CMAKE_OSX_SYSROOT because that can be 
an unresolved name. Also, if the resolved path of the CMAKE_OSX_SYSROOT is 
used as the value of CMAKE_SYSROOT, then that will be a search prefix, and 
the path modification suggested in that mail will not be needed.

I have also not yet addressed the INSTALL_PREFIX issues here:

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7292/focus=7373

I think the mail from Samuel Martin does not change any significant facts 
about the design. It seems from my reading that in his case, he would set 
CMAKE_EXTERNAL_INSTALL_PREFIX.

Can I go ahead and investigate implementing what is described in the above 
linked mail with CMAKE_EXTERNAL_INSTALL_PREFIX? Any updated ideas for a name 
for the variable?

Thanks,

Steve.


--

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] CTest: Request review of topic "ctest-fix-run-serial"

[Nils Gladitz]

On 21.10.2013 19:04, Bill Hoffman wrote:


It would also be good to merge your test case 
http://pastebin.com/3zXsTrem into its own test or one of these:
I created a new test case " CTestTestSerialInDepends" which now detects 
the issue but because of the sporadic nature of the issue may falsly 
report success.
I think it is still usefull though since the probability of detection is 
high and increases with the number of test machines and test runs.


Nils

--

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] Roadmap to CMake 3.0

[Robert Maynard]

Maybe given the known list of changes we should create a goal date for
CMake 3.0
That way if developers have a target to hit if they want to add to the
CMake 3.0 release.


On Mon, Oct 21, 2013 at 2:30 PM, Brad King  wrote:
> On 10/21/2013 02:21 PM, Rolf Eike Beer wrote:
>>> Potential changes motivating a major version number bump include:
>>
>> One thing I was thinking about was to really have lists as lists internally.
>> Once you touch a variable in a list way (e.g. set() with more than one
>> argument or any of the list() commands) a std::vector<> would be internally
>> created and maintained as long as no non-list command (e.g. set() with only
>> one argument that does not contain semicolons) is used on that variable. That
>> way all following list-style accesses would be much faster. And even
>> semicolons in list elements would work that way.
>
> In the long run this would be a nice internal cleanup.
>
> However, please see:
>
>  
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8207/focus=8220
>  On 10/11/2013 04:30 PM, Brad King wrote:
>  > FYI, I started this roadmap thread to enumerate *already-ongoing* work
>  > that justifies a move to 3.0.  This is not a call for wishlist items :)
>
> I don't want to enumerate a list of huge changes and delay the release
> until they are all ready.  Everything on my original roadmap is
> something already done.  I've accumulated these topics locally for over
> a year and need a major version number bump to integrate them.
>
> -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
--

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] CTest: Request review of topic "ctest-fix-run-serial"

[Nils Gladitz]

Hello Bill,

thanks for checking up on the changes!

On 21.10.2013 19:04, Bill Hoffman wrote:


Can you add a few comments into the code that describe what you are 
doing so it will be easier to follow?   Maybe a block comment that 
describes the high level approach?



I've added comments to the code blocks in CreateTestCostList().


// This should work:
if(this->Tests[test].size() == 0)

Changed.



It would also be good to merge your test case 
http://pastebin.com/3zXsTrem into its own test or one of these:


CTestTestParallel.
I am not yet entirely sure how to do that since the test case (and the 
underlying behavior in vanilla cmake) is sporadic and still needs some 
machine detectable failure condition but I'll try looking into it.




I am also getting a test failure here:

190: Test project C:/Users/hoffman/Work/My 
Builds/cmake-ninja/Tests/CTestTestStopTime

190: Start 1: TestSleep
190: 1/2 Test #1: TestSleep    Passed 29.99 sec
190: Start 2: ShouldNotRun
190: 2/2 Test #2: ShouldNotRun .***Failed 30.00 sec
190:
190: 50% tests passed, 1 tests failed out of 2
190:
190: Total Test time (real) =  60.00 sec
190:
190: The following tests FAILED:
190:  2 - ShouldNotRun (Failed)
1/1 Test #190: CTestTestStopTime ***Failed Required 
regular expression not found.Regex=[The stop time has been passed

] 60.67 sec


I haven't see that fail on my local test runs.
Is it sporadic or does it fail for you consistently?

Nils

--

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] Roadmap to CMake 3.0

[Matthew Woehlke]

On 2013-10-21 13:36, Alexander Neundorf wrote:

On Friday 11 October 2013, Brad King wrote:

Hi Folks,

I think the time has come for a major version number bump to go with
some major updates.  I propose to skip preparing 2.8.13 in 'master'
and go straight to 3.0.0.

Potential changes motivating a major version number bump include:

* Drop implementation of compatibility modes with CMake versions
   prior to 2.4.0 which is now over 7 years old.


Would this also be a chance to change the if( STREQUAL ) string vs. variable
lookup rules ?


That would be *awesome* :-D.

Relatedly, though I imagine it could be done with a policy at any time, 
it would be nice to explicitly disallow variable names that are not 
valid C++ identifiers (i.e. that don't match "[[:alnum:]_]+"). This at 
least would make it reliable to do like:


  if ("%${var}" STREQUAL "%value")

...with even further reduced danger that "%${var}" is a variable name.


Or introduce the whole set of comparison operators ("==", "<", etc.), which
would then never do variable lookup, and "deprecate" the current ones ?


That's come up before and been rejected.

IMHO the "correct" solution is to not do implicit expansion on quoted 
arguments. This might still need a policy, but it's much less likely 
anything in quotes is expected to be a variable name. However as I 
understand it, actually doing that is hard.


Also relatedly, it would be nice to actually handle lists as a separate 
data type (e.g. so list expansion doesn't have so many weird corner 
cases, lists can be nested, etc.). But again, hard :-(.


--
Matthew

--

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] Roadmap to CMake 3.0

[Rolf Eike Beer]

Am Montag, 21. Oktober 2013, 14:30:47 schrieb Brad King:
> On 10/21/2013 02:21 PM, Rolf Eike Beer wrote:
> >> Potential changes motivating a major version number bump include:
> > One thing I was thinking about was to really have lists as lists
> > internally. Once you touch a variable in a list way (e.g. set() with more
> > than one argument or any of the list() commands) a std::vector<> would be
> > internally created and maintained as long as no non-list command (e.g.
> > set() with only one argument that does not contain semicolons) is used on
> > that variable. That way all following list-style accesses would be much
> > faster. And even semicolons in list elements would work that way.
> 
> In the long run this would be a nice internal cleanup.
> 
> However, please see:
> 
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8207/focus
> =8220
>  On 10/11/2013 04:30 PM, Brad King wrote:
>  > FYI, I started this roadmap thread to enumerate *already-ongoing* work
>  > that justifies a move to 3.0.  This is not a call for wishlist items :)
> 
> I don't want to enumerate a list of huge changes and delay the release
> until they are all ready.  Everything on my original roadmap is
> something already done.  I've accumulated these topics locally for over
> a year and need a major version number bump to integrate them.

Since it doesn't change any public API it could go in at any time. I'll see if 
I find time hacking on this, and them you can take it whenever it is finished.

Eike

signature.asc
Description: This is a digitally signed message part.
--

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] Roadmap to CMake 3.0

[Brad King]

On 10/21/2013 02:21 PM, Rolf Eike Beer wrote:
>> Potential changes motivating a major version number bump include:
> 
> One thing I was thinking about was to really have lists as lists internally. 
> Once you touch a variable in a list way (e.g. set() with more than one 
> argument or any of the list() commands) a std::vector<> would be internally 
> created and maintained as long as no non-list command (e.g. set() with only 
> one argument that does not contain semicolons) is used on that variable. That 
> way all following list-style accesses would be much faster. And even 
> semicolons in list elements would work that way.

In the long run this would be a nice internal cleanup.

However, please see:

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8207/focus=8220
 On 10/11/2013 04:30 PM, Brad King wrote:
 > FYI, I started this roadmap thread to enumerate *already-ongoing* work
 > that justifies a move to 3.0.  This is not a call for wishlist items :)

I don't want to enumerate a list of huge changes and delay the release
until they are all ready.  Everything on my original roadmap is
something already done.  I've accumulated these topics locally for over
a year and need a major version number bump to integrate them.

-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] Roadmap to CMake 3.0

[Rolf Eike Beer]

> Potential changes motivating a major version number bump include:

One thing I was thinking about was to really have lists as lists internally. 
Once you touch a variable in a list way (e.g. set() with more than one 
argument or any of the list() commands) a std::vector<> would be internally 
created and maintained as long as no non-list command (e.g. set() with only 
one argument that does not contain semicolons) is used on that variable. That 
way all following list-style accesses would be much faster. And even 
semicolons in list elements would work that way.

Eike

signature.asc
Description: This is a digitally signed message part.
--

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] if() auto-dereference (was: Roadmap to CMake 3.0)

[Brad King]

On 10/21/2013 01:36 PM, Alexander Neundorf wrote:
> Would this also be a chance to change the if( STREQUAL ) string vs. variable 
> lookup rules ?
> Hmm, simply changing the behaviour would most probably break a lot of stuff.
> Maybe with a policy ?
> I.e. never do variable lookup, always just compare the strings

The current behavior is too in-grained to drop auto-dereference outright.
At most I would consider making it conditional on the argument quoting
as I proposed here:

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6377/focus=6379

For example:

 if(maybevar STREQUAL "value")

will dereference the variable but

 if("maybevar" STREQUAL "value")

would not.  That way one could ensure no auto-dereference by always
quoting both sides, which is good practice anyway.  We need
auto-dereference for the common

 if(SOME_VARIABLE)

to continue working.

This would have to be done with a policy whose warning triggers only when
the output of a conditional will be different.  It will also require
some internal changes in the way CMake tracks command arguments because
if() will now need to know how an argument was quoted.

Side note: As soon as CMP0028 is in master I have CMP0029 through
CMP0036 ready to disallow a bunch of old commands, so don't try
implementing this with a policy number below CMP0037.

As for a place in the roadmap, I think the list of major changes
for 3.0 is already enough to ask users to understand, and the proposed
policy may trigger a *lot* of warnings.  Since this will be done with a
policy it can be done at any time.

> Or introduce the whole set of comparison operators ("==", "<", etc.), which 
> would then never do variable lookup, and "deprecate" the current ones ?

That was discussed and IIRC rejected in the above-linked thread.
The operators are simply not informative enough about how the
comparison is to be done.

-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] Roadmap to CMake 3.0

[Alexander Neundorf]

On Friday 11 October 2013, Brad King wrote:
> Hi Folks,
> 
> I think the time has come for a major version number bump to go with
> some major updates.  I propose to skip preparing 2.8.13 in 'master'
> and go straight to 3.0.0.  If necessary it would still be possible
> to support 2.8.12.1+ or 2.8.13+ maintenance releases by basing topics
> on older versions instead of master.
> 
> The reasons we've been on 2.8.x for so long are:
> 
> * 2.9. was taken by CVS development versions when the 2.8.x
>   series started just before conversion to Git.
> 
> * 2.10 cannot be used because CMAKE_VERSION and if(. VERSION_LESS .)
>   did not exist prior to CMake 2.6.3 so old code does floating-point
>   comparisons of version numbers like 2.4, and 2.10 will look like
>   2.1 to such code.  This will not be a problem for 3.x versions.
> 
> * 3.x has been reserved for the future time when we have some major
>   changes underway.  This time has come.
> 
> Potential changes motivating a major version number bump include:
> 
> * New documentation system using reStructuredText and Sphinx.  This
>   will not be 100% workflow-compatible with the old documentation
>   system as discussed in the relevant thread.
> 
> * Policy CMP0026 changes behavior of the commonly-used LOCATION target
>   property in favor of generator expressions.  This is needed to move
>   more logic to generate-time where it belongs.  Steve can explain in
>   more detail if anyone wants.  A draft of this is already in 'next'.
> 
> * New quoting syntax: Lua-style long-brackets.  Quoting opens with
>   "[" followed by zero or more "=" followed by "[" and closes with
>   "]" followed by the same number of "=" followed by "]".  No
>   evaluation is performed on the content.  It is very nice for
>   inline literal content.
> 
>   This is an incompatible change because unquoted arguments starting
>   in "[[", "[=[", etc. will now be treated as opening long brackets
>   (expecting a matching close bracket) instead of unquoted arguments.
>   CMake 2.8.12 added a warning for this case.  This happens at the
>   parsing stage so we cannot use a policy for it.  Fortunately this
>   should be a rare occurrence in practice, but still should come
>   with a major version number bump.
> 
> * The "cmake --build" tool should share stdout and stderr with the
>   caller instead of separately buffering/merging them.  This will be
>   an incompatible change possibly affecting user scripts in ways that
>   should only come with a major version bump and release notes.
> 
> * New policies to disable old commands that require significant
>   amounts of C++ code to be kept around just to support them.
>   These include (but may not be limited to):
> 
>   - exec_program: replaced by execute_process
>   - export_library_dependencies: replaced by export()/install(EXPORT)
>   - load_command: replaced by macros and functions; does not work
> when the toolchain does not match the CMake binary anyway
>   - output_required_files: obscure
> 
> * Drop the "cmake -i" wizard mode.  This has long been replaced by
>   ccmake, cmake-gui, or just cmake with -D options.
> 
> * Drop implementation of compatibility modes with CMake versions
>   prior to 2.4.0 which is now over 7 years old.

Would this also be a chance to change the if( STREQUAL ) string vs. variable 
lookup rules ?
Hmm, simply changing the behaviour would most probably break a lot of stuff.
Maybe with a policy ?
I.e. never do variable lookup, always just compare the strings, and maybe warn 
if there is a variable named like one of the strings ?
Or introduce the whole set of comparison operators ("==", "<", etc.), which 
would then never do variable lookup, and "deprecate" the current ones ?

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] CTest: Request review of topic "ctest-fix-run-serial"

[Bill Hoffman]

On 10/18/2013 6:50 PM, Nils Gladitz wrote:

Hello Bill,

I've updated the topic with (I think) improved sorting.
Tests are now prioritized by depth within the dependency graph and
within each depth level they are further ordered by cost.
This gives better total test time for my test case and preserves
correctness in relation to RUN_SERIAL
Can you add a few comments into the code that describe what you are 
doing so it will be easier to follow?   Maybe a block comment that 
describes the high level approach?



Also, small change, I don't think we need this copy anymore:
 // copy the depend tests locally because when
  // a test is finished it will be removed from the depend list
  // and we don't want to be iterating a list while removing from it
  TestSet depends = this->Tests[test];
  size_t totalDepends = depends.size();

// This should work:
if(this->Tests[test].size() == 0)


It would also be good to merge your test case 
http://pastebin.com/3zXsTrem into its own test or one of these:


CTestTestParallel.

I am also getting a test failure here:

190: Test project C:/Users/hoffman/Work/My 
Builds/cmake-ninja/Tests/CTestTestStopTime

190: Start 1: TestSleep
190: 1/2 Test #1: TestSleep    Passed   29.99 sec
190: Start 2: ShouldNotRun
190: 2/2 Test #2: ShouldNotRun .***Failed   30.00 sec
190:
190: 50% tests passed, 1 tests failed out of 2
190:
190: Total Test time (real) =  60.00 sec
190:
190: The following tests FAILED:
190:  2 - ShouldNotRun (Failed)
1/1 Test #190: CTestTestStopTime ***Failed  Required 
regular expression not found.Regex=[The stop time has been passed

] 60.67 sec


Thanks.

-Bill

--

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] Ninja: using dependency database

[Bill Hoffman]

On 10/21/2013 12:24 PM, Peter Kümmel wrote:


When I revert my patch the test still fails, I have to check if why.
Looks like a spaces in the path issue to me.  Are you testing with 
spaces in your path?


-Bill

--

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] Ninja: using dependency database

[David Cole]

Is there some simple test we can do to make sure ninja is
the right version?


We could check the output of ninja --version


You could, but it won't be 100% reliable.

I just built ninja from git master, and it reports "1.4.0.git" as its 
--version output.


So... you know it came from git *after* 1.4.0, but you don't know for 
sure if it includes the change you require or not. If it's LESS than 
1.4.0, or the version number is not even present, then you could warn 
that the ninja is definitely too old.


But if it's "1.4.0.git" then you don't know if it's too old or not.


D

--

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] Ninja: using dependency database

[Bill Hoffman]

On 10/21/2013 12:26 PM, Peter Kümmel wrote:

Is there some simple test we can do to make sure ninja is
the right version?


We could check the output of ninja --version

My version says:  $ ninja --version
git


It is pretty old does it say something different now?

-Bill

--

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] Ninja: using dependency database

[Peter Kümmel]

On 21.10.2013 16:12, Brad King wrote:

On 10/21/2013 09:44 AM, Peter Kümmel wrote:

Locally all tests have passed. Why is KWStyle disabled and
runs only on the server?


It requires an external tool.  It would be enabled locally if
you had the tool.  Also regardless of local testing you should
be monitoring the dashboard, and these errors have been there
since you merged your topic.

If you follow the developer setup instructions here:

  http://www.cmake.org/Wiki/CMake/Git/Develop


Thanks, and sorry for the "communication round trip", it was 
obvious.




you should get a local hook that won't allow commits with long
lines.

-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] Ninja: using dependency database

[Peter Kümmel]

On 21.10.2013 16:19, Bill Hoffman wrote:

On 10/19/2013 7:09 AM, Peter Kümmel wrote:

CMake now uses Ninja's database feature for dependency
tracking.
An empty build now takes about a third less (e.g. Clang
160ms->100ms)

Therefore ninja master is needed, please update your build
server.


This looks like a real bug:
http://open.cdash.org/testDetails.php?test=214096074&build=3067806


When I revert my patch the test still fails, I have to check 
if why.






Run Build Command:/home/kitware/Dashboards/My\
Tests/ninja/ninja
[1/8] Building C object "/home/kitware/Dashboards/My
Tests/CMake-ninja-build/Tests/OutOfBinary/CMakeFiles/outlib.dir/outlib.c.o"

[2/8] Building CXX object
SubDir/OutOfSourceSubdir/CMakeFiles/testlib.dir/testlib.cxx.o
FAILED: /usr/bin/cc-MMD -MT "/home/kitware/Dashboards/My
Tests/CMake-ninja-build/Tests/OutOfBinary/CMakeFiles/outlib.dir/outlib.c.o"
-MF "/home/kitware/Dashboards/My
Tests/CMake-ninja-build/Tests/OutOfBinary/CMakeFiles/outlib.dir/outlib.c.o.d"
-o "/home/kitware/Dashboards/My
Tests/CMake-ninja-build/Tests/OutOfBinary/CMakeFiles/outlib.dir/outlib.c.o"
   -c "/home/kitware/Dashboards/My
Tests/NinjaCMake/Tests/OutOfBinary/outlib.c"
depfile has multiple output paths.
ninja: build stopped: subcommand failed.


-Bill

--

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



--

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] Ninja: using dependency database

[Peter Kümmel]

On 21.10.2013 16:13, Bill Hoffman wrote:

On 10/21/2013 9:06 AM, Brad King wrote:

>Therefore ninja master is needed, please update your build
>server.

Is there a way we can get a better error message telling
people they need to upgrade ninja?

http://open.cdash.org/viewConfigure.php?buildid=3067884
Configure Output:
-- The C compiler identification is GNU 4.2.1
-- The CXX compiler identification is GNU 4.2.1
-- Check for working C compiler using: Ninja
-- Check for working C compiler using: Ninja -- broken
CMake Error at
/home/dashboard/BotFarm/Chameleon-14/CMake/Default/CMake/Modules/CMakeTestCCompiler.cmake:61
(message):
   The C compiler "/usr/bin/cc" is not able to compile a
simple test program.
   It fails with the following output:
  
   ninja: error: rules.ninja:18: unexpected variable 'deps'=
 deps = gcc
   ^ near here


Is there some simple test we can do to make sure ninja is
the right version?


We could check the output of ninja --version




-Bill
--

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



--

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] CheckTypeSize: Add support for C++

[Brad King]

On 10/21/2013 10:41 AM, Daniele E. Domenichelli wrote:
> Does it seem ok now? Can I merge to next?

Yes, please.

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] CheckTypeSize: Add support for C++

[Daniele E. Domenichelli]

On 21/10/13 14:50, Brad King wrote:
>> The state will change from doing=LANGUAGE to doing=unset without
>> setting the language, therefore C will be used and no error/warning is
>> shown to the user.
> 
> When LANGUAGE is encountered, set the language to empty so that it
> will be an error if the language does not get set.


Ok thanks! Done and pushed again.

Does it seem ok now? Can I merge to next?


Cheers,
 Daniele
--

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] Ninja: using dependency database

[Bill Hoffman]

On 10/19/2013 7:09 AM, Peter Kümmel wrote:

CMake now uses Ninja's database feature for dependency tracking.
An empty build now takes about a third less (e.g. Clang 160ms->100ms)

Therefore ninja master is needed, please update your build server.


This looks like a real bug:
http://open.cdash.org/testDetails.php?test=214096074&build=3067806


Run Build Command:/home/kitware/Dashboards/My\ Tests/ninja/ninja
[1/8] Building C object "/home/kitware/Dashboards/My 
Tests/CMake-ninja-build/Tests/OutOfBinary/CMakeFiles/outlib.dir/outlib.c.o"
[2/8] Building CXX object 
SubDir/OutOfSourceSubdir/CMakeFiles/testlib.dir/testlib.cxx.o
FAILED: /usr/bin/cc-MMD -MT "/home/kitware/Dashboards/My 
Tests/CMake-ninja-build/Tests/OutOfBinary/CMakeFiles/outlib.dir/outlib.c.o" 
-MF "/home/kitware/Dashboards/My 
Tests/CMake-ninja-build/Tests/OutOfBinary/CMakeFiles/outlib.dir/outlib.c.o.d" 
-o "/home/kitware/Dashboards/My 
Tests/CMake-ninja-build/Tests/OutOfBinary/CMakeFiles/outlib.dir/outlib.c.o" 
  -c "/home/kitware/Dashboards/My 
Tests/NinjaCMake/Tests/OutOfBinary/outlib.c"

depfile has multiple output paths.
ninja: build stopped: subcommand failed.


-Bill

--

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] Ninja: using dependency database

[Bill Hoffman]

On 10/21/2013 9:06 AM, Brad King wrote:

>Therefore ninja master is needed, please update your build
>server.
Is there a way we can get a better error message telling people they 
need to upgrade ninja?


http://open.cdash.org/viewConfigure.php?buildid=3067884
Configure Output:
-- The C compiler identification is GNU 4.2.1
-- The CXX compiler identification is GNU 4.2.1
-- Check for working C compiler using: Ninja
-- Check for working C compiler using: Ninja -- broken
CMake Error at 
/home/dashboard/BotFarm/Chameleon-14/CMake/Default/CMake/Modules/CMakeTestCCompiler.cmake:61 
(message):
  The C compiler "/usr/bin/cc" is not able to compile a simple test 
program.

  It fails with the following output:
 
  ninja: error: rules.ninja:18: unexpected variable 'deps'=
deps = gcc
  ^ near here


Is there some simple test we can do to make sure ninja is the right version?


-Bill
--

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] Ninja: using dependency database

[Brad King]

On 10/21/2013 09:44 AM, Peter Kümmel wrote:
> Locally all tests have passed. Why is KWStyle disabled and 
> runs only on the server?

It requires an external tool.  It would be enabled locally if
you had the tool.  Also regardless of local testing you should
be monitoring the dashboard, and these errors have been there
since you merged your topic.

If you follow the developer setup instructions here:

 http://www.cmake.org/Wiki/CMake/Git/Develop

you should get a local hook that won't allow commits with long
lines.

-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] double-colon-is-imported topic

[Stephen Kelly]

Brad King wrote:

> Steve,
> 
> This topic fails ExportImport on a few builds:
> 
>  http://open.cdash.org/testDetails.php?test=214179551&build=3068327
>  Error! E068: invalid option
>  Note! N746: processing command line, switch: -Dbld::IFACE_TRY_COMPILE
> 
>  http://open.cdash.org/testDetails.php?test=214180406&build=3068333
>  Command-line error: invalid macro definition: bld::IFACE_TRY_COMPILE
> 
> Even on Linux with Makefile generators I see:
> 
>  $ cd Tests/ExportImport/Import
>  $ grep -r Dbld:: *
>  CMakeFiles/CMakeOutput.log:/usr/bin/c++   -DHEADERONLY_DEFINE
>  -Dbld::IFACE_TRY_COMPILE ... src.cxx
> 
> This should not be passing "::" in a preprocessor macro name.
> Please take a look.

Ok, fixed now.

Thanks,

Steve.


--

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] Ninja: using dependency database

[Peter Kümmel]

On 21.10.2013 15:06, Brad King wrote:

On 10/19/2013 07:09 AM, Peter Kümmel wrote:

CMake now uses Ninja's database feature for dependency tracking.
An empty build now takes about a third less (e.g. Clang
160ms->100ms)

Therefore ninja master is needed, please update your build
server.


Meanwhile, please fix the line length violations in your topic.


Locally all tests have passed. Why is KWStyle disabled and 
runs only on the server?




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

[cmake-developers] [CMake 0014501]: Add Clojure support ?

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14501 
== 
Reported By:hadim
Assigned To:
== 
Project:CMake
Issue ID:   14501
Category:   Modules
Reproducibility:have not tried
Severity:   feature
Priority:   high
Status: new
== 
Date Submitted: 2013-10-21 15:16 CEST
Last Modified:  2013-10-21 15:16 CEST
== 
Summary:Add Clojure support ?
Description: 
I am converting a complex autotools project to cmake. I am stuck because some of
the jar files are generated from Clojure

I would like to know if UseJave.cmake (add_jar and install_jar) could support
clojure build ?

This is the kind of command I found in the Makefile.am file:

java -server -cp jar1:jar2:another_jar:path/to/clojure.jar
-Djava.awt.headless=true -Dclojure.compile.path=./classes/ -server
clojure.lang.Compile org.path.to.my_clojure_module
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-10-21 15:16 hadim  New Issue
==

--

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] double-colon-is-imported topic

[Brad King]

Steve,

This topic fails ExportImport on a few builds:

 http://open.cdash.org/testDetails.php?test=214179551&build=3068327
 Error! E068: invalid option
 Note! N746: processing command line, switch: -Dbld::IFACE_TRY_COMPILE

 http://open.cdash.org/testDetails.php?test=214180406&build=3068333
 Command-line error: invalid macro definition: bld::IFACE_TRY_COMPILE

Even on Linux with Makefile generators I see:

 $ cd Tests/ExportImport/Import
 $ grep -r Dbld:: *
 CMakeFiles/CMakeOutput.log:/usr/bin/c++   -DHEADERONLY_DEFINE 
-Dbld::IFACE_TRY_COMPILE ... src.cxx

This should not be passing "::" in a preprocessor macro name.
Please take a look.

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

[cmake-developers] [CMake 0014500]: UseJava.cmake add_jar() resource files: specify relative path

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14500 
== 
Reported By:hadim
Assigned To:
== 
Project:CMake
Issue ID:   14500
Category:   Modules
Reproducibility:have not tried
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2013-10-21 09:08 EDT
Last Modified:  2013-10-21 09:08 EDT
== 
Summary:UseJava.cmake add_jar() resource files: specify
relative path
Description: 
I didn't find a clean way to specify path for resource files. For example I have
a file called ./a/path/text_linux.config and I would like to add it at the
source of the jar file (if I also can rename it, it will be awesome !).

add_jar(MY_TARGET
SOURCES ${source_files}
./a/path/text_linux.config 

INCLUDE_JARS ${some_jars})

In the generated jar file, my resource file is under ./a/path/text_linux.config
and I would like to have it under ./text.config for example.

Any idea ?
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-10-21 09:08 hadim  New Issue
==

--

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] Ninja: using dependency database

[Brad King]

On 10/19/2013 07:09 AM, Peter Kümmel wrote:
> CMake now uses Ninja's database feature for dependency tracking.
> An empty build now takes about a third less (e.g. Clang 
> 160ms->100ms)
> 
> Therefore ninja master is needed, please update your build 
> server.

Meanwhile, please fix the line length violations in your topic.

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] CheckTypeSize: Add support for C++

[Brad King]

On 10/21/2013 05:14 AM, Daniele E. Domenichelli wrote:
> This will cause
> 
>   check_type_size(int SIZEOF_INT LANGUAGE BUILTIN_TYPES_ONLY)
> 
> to be accepted by this state

Yes, but many other places already do the same thing.

> The state will change from doing=LANGUAGE to doing=unset without
> setting the language, therefore C will be used and no error/warning is
> shown to the user.

When LANGUAGE is encountered, set the language to empty so that it
will be an error if the language does not get set.

-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] Patches for Visual Studio multi-CPU architecture project generation and a Windows-Phone-8 generator

[Paul Annetts]

To differentiate between Windows Store and Windows desktop apps.

Paul.

From: Patrick Gansterer
Sent: ‎21/‎10/‎2013 09:12
To: Paul Annetts
Cc: 'Brad King'; 
cmake-developers@cmake.org
Subject: Re: [cmake-developers] Patches for Visual Studio multi-CPU 
architecture project generation and a Windows-Phone-8 generator


On 21.10.2013, at 10:08, Paul Annetts wrote:
> Patrick's comments about using CMAKE_GENERATOR_TOOLSET have made me think we 
> should have a combined "Visual Studio 11 2012 Windows-Store" generator using 
> CMAKE_GENERATOR_TOOLSET to switch between Windows Store and Windows Phone.
> (The Windows Store and Phone C/C++ APIs are very similar, but don't share an 
> ABI).

Why do you need the special "Windows-Store" generator then?

-- 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

[cmake-developers] [CMake 0014499]: Add support for .NET target framework version for VS 2008

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14499 
== 
Reported By:mar-na
Assigned To:
== 
Project:CMake
Issue ID:   14499
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2013-10-21 07:54 EDT
Last Modified:  2013-10-21 07:54 EDT
== 
Summary:Add support for .NET target framework version for VS
2008
Description: 
I want set the .net target framework for a managed C++ project. I use VS 2008
but cmake currently support the target property
VS_DOTNET_TARGET_FRAMEWORK_VERSION only for VS 2010.

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-10-21 07:54 mar-na New Issue
==

--

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 0014498]: Folder references aren't added correctly to Xcode projects.

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14498 
== 
Reported By:Michael Priestman
Assigned To:
== 
Project:CMake
Issue ID:   14498
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2013-10-21 05:51 EDT
Last Modified:  2013-10-21 05:51 EDT
== 
Summary:Folder references aren't added correctly to Xcode
projects.
Description: 
With the change that fixed issue 0014093, another issue has arisen.

If you try to add a folder reference into an Xcode project, then the incorrect
file type is set on the reference, and Xcode cannot access the files inside the
folder, saying instead that it has no permissions.

I have a folder that contains some image assets for an iOS project, and I want
to just add the entire folder (which has subfolders) to an Xcode project. I do
this by just including the path to the folder.

With CMake 2.8.11.02, this worked fine. But with the change mentioned above, the
reference now has an "explicitFileType" attribute, which is set to "sourcecode".
It appears Xcode isn't happy with this.

If you add a folder reference to an Xcode project, I think the explicitFileType
attribute should be set to "folder". I discovered this by explicitly setting the
file type in Xcode to "Directory" and resaving the project. If you do this, then
Xcode can once again access the contents of the folder.

So whilst technically this could be a bug with Xcode (tested with 4 and 5, same
behaviour), I don't think it should be too hard to fix in CMake. If you can tell
a given source file reference is actually a folder reference, then you can just
say the explicitFileType is "folder" instead of "sourcecode".

This isn't a major issue as if you want to access the folder in Xcode, you can
just manually update the file type, but obviously you'd have to do that each
time you regenerate the project.

Steps to Reproduce: 
Create a directory that contains a simple source file and single folder that
contains, say, an image.

Create a simple CMake file that defines a library that contains a reference to
the folder.

Generate an XCode project from the CMake file.

Load XCode project, and try to navigate to the folder. You will get an error.

Set the file type to "Directory", then you can access the contents of the
folder.

Attached is a sample that demonstrates this problem.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-10-21 05:51 Michael PriestmanNew Issue
2013-10-21 05:51 Michael PriestmanFile Added: sample.zip   
==

--

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] CheckTypeSize: Add support for C++

[Daniele E. Domenichelli]

On 18/10/13 16:42, Brad King wrote:
> +if("x${arg}" MATCHES "^x(BUILTIN_TYPES_ONLY)$" AND "x${doing}" MATCHES 
> "^x$")
> 
> Generally the convention in similar state machines elsewhere
> is to not allow a keyword to be a value for a preceding keyword,
> so you don't need the AND here.
[...]
> So the block can be (untested):
> 
>  if("x${arg}" STREQUAL "xBUILTIN_TYPES_ONLY")
>set(_CHECK_TYPE_SIZE_${arg} 1)
>unset(doing)


This will cause

  check_type_size(int SIZEOF_INT LANGUAGE BUILTIN_TYPES_ONLY)

to be accepted by this state, while in my opinion it should report an
error. The state will change from doing=LANGUAGE to doing=unset without
setting the language, therefore C will be used and no error/warning is
shown to the user.

  AND "x${doing}" MATCHES "^x$"

was checking exactly this, in order to accept the keyword as value for
LANGUAGE and then show an unknown language "BUILTIN_TYPES_ONLY" error.

Should I just accept it and consider this correct?


Cheers,
 Daniele
--

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] Patches for Visual Studio multi-CPU architecture project generation and a Windows-Phone-8 generator

[Patrick Gansterer]

On 21.10.2013, at 10:08, Paul Annetts wrote:
> Patrick's comments about using CMAKE_GENERATOR_TOOLSET have made me think we 
> should have a combined "Visual Studio 11 2012 Windows-Store" generator using 
> CMAKE_GENERATOR_TOOLSET to switch between Windows Store and Windows Phone. 
> (The Windows Store and Phone C/C++ APIs are very similar, but don't share an 
> ABI).

Why do you need the special "Windows-Store" generator then?

-- 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] Patches for Visual Studio multi-CPU architecture project generation and a Windows-Phone-8 generator

[Paul Annetts]

Thanks Brad, sounds like a plan.

Patrick's comments about using CMAKE_GENERATOR_TOOLSET have made me think we 
should have a combined "Visual Studio 11 2012 Windows-Store" generator using 
CMAKE_GENERATOR_TOOLSET to switch between Windows Store and Windows Phone. 
 (The Windows Store and Phone C/C++ APIs are very similar, but don't share an 
ABI).

I think it could simplify future work on the generator and potentially make it 
more widely applicable. Would it be feasible in future to update this 
generator's findPackage() to make it toolset and platform aware, without 
breaking existing generator behaviour?

What do you think?

Paul.
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: 18 October 2013 17:52
To: Paul Annetts
Cc: 'Patrick Gansterer'; cmake-developers@cmake.org
Subject: Re: [cmake-developers] Patches for Visual Studio multi-CPU 
architecture project generation and a Windows-Phone-8 generator

On 10/18/2013 12:03 PM, Paul Annetts wrote:
> Any multi-CPU arch generator which tries to at one point during the 
> CMAKE configure step to determine endianess or sizeof(T*) is always going to 
> get the answer wrong for one or more of those architectures. It is not 
> difficult to find out these values from the compiler or standard C/C++. 
> However such a generator will share a common API across the CPU archs and so 
> have the potential to add significant user benefit.
> 
> My experience is that WP8 benefits greatly from multi-platform support, so 
> that practical usage of CMAKE is kept simple and flexible for end users. In 
> my opinion this outweighs the theoretical benefit of find_package() for WP8 
> (for a sum total of 0 current compatible binaries).
> 
> ​However on balance I don’t think adding multi-platform to the general VS 
> toolchain adds any value. For example there’s no point in compiling CMAKE for 
> x64 as it doesn't need to address > 4GB RAM and it won't even be possible to 
> compile it for ARM as CMAKE can’t run under Windows 8 RT.

Okay, I think we can work with adding the CMAKE_GENERATOR_PLATFORMS variable to 
specify the list of platforms (what you called CMAKE_MSVC_PLATFORMS).  It can 
be documented as supported only by the WP8 generators for now.  If a project or 
user sets the variable they are responsible for making the build work that way. 
 It won't appear by default or be used by other generators so no one else will 
be affected.

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

[cmake-developers] [CMake 0014497]: Ninja & CMake 2.8.12: warning when generating resource file out of source tree

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=14497 
== 
Reported By:Gregoire
Assigned To:
== 
Project:CMake
Issue ID:   14497
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2013-10-21 03:51 EDT
Last Modified:  2013-10-21 03:51 EDT
== 
Summary:Ninja & CMake 2.8.12: warning when generating
resource file out of source tree
Description: 

Issue happens when I generate a resource file in the build tree (out of source)
on windows (msvc or mingw) using "Ninja" generator.

If I generate the resource inside the source tree, no issue.
If I generate a source (not a resource), no issue for both in source and build
trees.
If I use native build tool (nmake or mingw32-make), no issue.

Steps to Reproduce: 
(See attached project)
Under Windows, use Ninja generator under windows in an out of source build tree
to generate the project.
The warning is displayed at build time when invoking ninja.

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-10-21 03:51 Gregoire   New Issue
2013-10-21 03:51 Gregoire   File Added: sources-ninja-resource-warning.zip  
 
==

--

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