[cmake-developers] [CMake 0014257]: The compilation progress indicator always shows 38%

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=14257 
== 
Reported By:thefirstdude02
Assigned To:
== 
Project:CMake
Issue ID:   14257
Category:   (No Category)
Reproducibility:have not tried
Severity:   trivial
Priority:   normal
Status: new
== 
Date Submitted: 2013-06-28 17:46 EDT
Last Modified:  2013-06-28 17:46 EDT
== 
Summary:The compilation progress indicator always shows 38%
Description: 
We had a large project which repeatedly hit a compiler or linker error at 38%. 
The build is managed by CMake, and worked correctly before we introduced the
bugs that caused the aforementioned compiler/linker errors.  We finally fixed
the bugs in our code, then re-ran CMake (clearing its cache), ran make clean,
and then ran make.  We were very confused to see the progress indicator always
read 38% throughout the compile and link process.  We terminated compilation and
did another make clean.  We then allowed make to run all the way through --- and
the build ran successfully from start to finish.  However, at every single step
along the way, the progress was reported as 38%.

The build works completely fine, just the progress indicator only ever reads
38%.

Steps to Reproduce: 
Not known?
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-06-28 17:46 thefirstdude02 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] Disallowing include() of export() result

[Brad King]

On 6/28/2013 12:49 PM, Brad King wrote:
> On 6/28/2013 12:27 PM, Matthew Woehlke wrote:
>> To me it would make much more sense if export() was more like 
>> install(EXPORT), where one declares at the point of the add_library() 
>> the desire to export a target, which adds to a list the CMake keeps 
>> track of internally in order to generate an export file later.
> 
> That is the end goal of what Steve is starting in this topic:
> to delay export() until generate time.

I meant to add that once this delay is in place then there will
not be much difference between APPEND and non-APPEND mode.

-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] Disallowing include() of export() result

[Brad King]

On 6/28/2013 12:27 PM, Matthew Woehlke wrote:
> To me it would make much more sense if export() was more like 
> install(EXPORT), where one declares at the point of the add_library() 
> the desire to export a target, which adds to a list the CMake keeps 
> track of internally in order to generate an export file later.

That is the end goal of what Steve is starting in this topic:
to delay export() until generate time.

-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] Disallowing include() of export() result

[Matthew Woehlke]

On 2013-06-28 09:06, Stephen Kelly wrote:

Brad King wrote:

Perhaps the policy could also disallow the
APPEND mode altogether.  IIRC I've participated in discussion
in the past about how APPEND is a bad approach anyway.


I've never used it, but then I've never used export() except in unit tests
of it either :). I don't think preserving the APPEND functionality is
expensive.


Do you not produce a fooConfig.cmake with export targets for your build 
directories? :-)


Projects I work on usually make two fooConfig.cmake's; one to be 
installed, and one that lets other projects use the project from its 
build directory. Both use exported targets, via install(EXPORT) and 
export() respectively.


--
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] Disallowing include() of export() result

[Matthew Woehlke]

On 2013-06-28 08:40, Brad King wrote:

What about the APPEND mode of export?  Do you plan to try to
collect all the appended pieces together, all delayed until
generate time?


That would be great if you could! One of my big gripes with export() is 
how much less elegant it is generating a build-time targets.cmake than 
at install time. If the calls to export() could be collected and parsed 
once (preferably without duplicating the boilerplate for every call) 
that would be a welcome improvement.



Perhaps the policy could also disallow the
APPEND mode altogether.  IIRC I've participated in discussion
in the past about how APPEND is a bad approach anyway.


Maybe I am unclear how export() is supposed to be used, but I have 
always used it as a trio of add_library()/export()/install() (often in a 
helper function), per library. That seems quite a bit more convenient 
than collecting a list of all targets in the project for one-time 
export(). Would this make the latter approach the only possible way to 
use export()? (That would probably break quite a few projects :-(.)


To me it would make much more sense if export() was more like 
install(EXPORT), where one declares at the point of the add_library() 
the desire to export a target, which adds to a list the CMake keeps 
track of internally in order to generate an export file later.


--
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] clang now warns: 'register' storage class specifier is deprecated

[Brad King]

On 6/28/2013 11:37 AM, Sean McBride wrote:
> I can make a patch to remove the 'register' keyword, if you will accept it.  
> Anyone have a philosophical objection?  If so, I will suppress the warning.

We can remove it from our code but for code imported from
third-party projects please suppress it instead (#pragma)
to keep the changes lighter.

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] clang now warns: 'register' storage class specifier is deprecated

[Robert Maynard]

I see no reason in using the register keyword. Currently compilers
ignore the register keyword, and basically it should be considered
noise when reading.


On Fri, Jun 28, 2013 at 11:37 AM, Sean McBride  wrote:
> Hi all,
>
> Recently in clang trunk, they added a new warning which we now see on Rogue7 
> since I updated my clang:
>
> 
>
> CMake/Source/kwsys/RegularExpression.cxx:347:5: warning: 'register' storage 
> class specifier is deprecated [-Wdeprecated-register]
> register const char* scan;
> ^
>
> I can make a patch to remove the 'register' keyword, if you will accept it.  
> Anyone have a philosophical objection?  If so, I will suppress the warning.
>
> Cheers,
>
> --
> 
> Sean McBride, B. Eng s...@rogue-research.com
> Rogue Researchwww.rogue-research.com
> Mac Software Developer  Montréal, Québec, Canada
>
>
> --
>
> 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] clang now warns: 'register' storage class specifier is deprecated

[Rolf Eike Beer]

Sean McBride wrote:
> Hi all,
> 
> Recently in clang trunk, they added a new warning which we now see on Rogue7
> since I updated my clang:
> 
> 
> 
> CMake/Source/kwsys/RegularExpression.cxx:347:5: warning: 'register' storage
> class specifier is deprecated [-Wdeprecated-register] register const char*
> scan;
> ^
> 
> I can make a patch to remove the 'register' keyword, if you will accept it. 
> Anyone have a philosophical objection?  If so, I will suppress the warning.

That code dates back until 1989/1991 according to the comments. At that time 
it may have been a good idea to hint the compiler which variables to put into 
registers, but I don't think that this would give much gain today. I remember 
having seen something like a year back where the register statement gave 
better code, but these thing should be very rare and compilers usually tend to 
improve.

So, IMHO: rip it off.

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

[cmake-developers] clang now warns: 'register' storage class specifier is deprecated

[Sean McBride]

Hi all,

Recently in clang trunk, they added a new warning which we now see on Rogue7 
since I updated my clang:



CMake/Source/kwsys/RegularExpression.cxx:347:5: warning: 'register' storage 
class specifier is deprecated [-Wdeprecated-register]
register const char* scan;
^

I can make a patch to remove the 'register' keyword, if you will accept it.  
Anyone have a philosophical objection?  If so, I will suppress the warning.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada


--

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 0014254]: With Xcode-5DP $CURRENT_ARCH is set to undefined_arch and makes OBJECT libraries fail to compile

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=14254 
== 
Reported By:Tobias Hieta
Assigned To:
== 
Project:CMake
Issue ID:   14254
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2013-06-28 11:19 EDT
Last Modified:  2013-06-28 11:19 EDT
== 
Summary:With Xcode-5DP $CURRENT_ARCH is set to
undefined_arch and makes OBJECT libraries fail to compile
Description: 
The following test example fails to work with the Xcode generator and Xcode
5DP-2

add_library(lib OBJECT lib.c)
add_executable(test test.c $)

The problem seems to be that CURRENT_ARCH is set to undefined_arch whatever I
try to select, Xcode buildlog:

CompileC b/Project.build/Debug/lib.build/Objects-normal/x86_64/lib.o lib.c
normal x86_64 c com.apple.compilers.llvm.clang.1_0.compiler
cd /Users/tru/Documents/Code/cmake-xcode-bug
setenv LANG en_US.US-ASCII
   
/Applications/Xcode5-DP2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-x c -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack
-fmacro-backtrace-limit=0 -Wno-trigraphs -fpascal-strings -O0
-Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type
-Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function
-Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value
-Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow
-Wno-four-char-constants -Wno-conversion -Wno-constant-conversion
-Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion
-Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof -DCMAKE_INTDIR=\"Debug\"
-isysroot
/Applications/Xcode5-DP2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
-fasm-blocks -fstrict-aliasing -Wdeprecated-declarations
-mmacosx-version-min=10.8 -g -Wno-sign-conversion
-I/Users/tru/Documents/Code/cmake-xcode-bug/b/Project.build/Debug/lib.build/Objects-normal/include
-I/Applications/Xcode5-DP2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
-I/Users/tru/Documents/Code/cmake-xcode-bug/b/Project.build/Debug/lib.build/DerivedSources/x86_64
-I/Users/tru/Documents/Code/cmake-xcode-bug/b/Project.build/Debug/lib.build/DerivedSources
-Wmost -Wno-four-char-constants -Wno-unknown-pragmas
-F/Users/tru/Documents/Code/cmake-xcode-bug/b/Project.build/Debug/lib.build/Objects-normal
-MMD -MT dependencies -MF
/Users/tru/Documents/Code/cmake-xcode-bug/b/Project.build/Debug/lib.build/Objects-normal/x86_64/lib.d
--serialize-diagnostics
/Users/tru/Documents/Code/cmake-xcode-bug/b/Project.build/Debug/lib.build/Objects-normal/x86_64/lib.dia
-c /Users/tru/Documents/Code/cmake-xcode-bug/lib.c -o
/Users/tru/Documents/Code/cmake-xcode-bug/b/Project.build/Debug/lib.build/Objects-normal/x86_64/lib.o
Libtool b/Project.build/Debug/lib.build/Objects-normal/liblib.a normal x86_64
cd /Users/tru/Documents/Code/cmake-xcode-bug
setenv MACOSX_DEPLOYMENT_TARGET 10.8
   
/Applications/Xcode5-DP2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool
-static -arch_only x86_64 -syslibroot
/Applications/Xcode5-DP2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
-L/Users/tru/Documents/Code/cmake-xcode-bug/b/Project.build/Debug/lib.build/Objects-normal
-filelist
/Users/tru/Documents/Code/cmake-xcode-bug/b/Project.build/Debug/lib.build/Objects-normal/x86_64/lib.LinkFileList
-o
/Users/tru/Documents/Code/cmake-xcode-bug/b/Project.build/Debug/lib.build/Objects-normal/liblib.a
CompileC b/Project.build/Debug/test.build/Objects-normal/x86_64/test.o test.c
normal x86_64 c com.apple.compilers.llvm.clang.1_0.compiler
cd /Users/tru/Documents/Code/cmake-xcode-bug
setenv LANG en_US.US-ASCII
   
/Applications/Xcode5-DP2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-x c -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack
-fmacro-backtrace-limit=0 -Wno-trigraphs -fpascal-strings -O0
-Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type
-Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function
-Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value
-Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow
-Wno-four-char-constants -Wno-conversion -Wno-constant-conversion
-Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion
-Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof 

[cmake-developers] [CMake 0014253]: Add generators for Visual Studio 2013

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14253 
== 
Reported By:Petter
Assigned To:
== 
Project:CMake
Issue ID:   14253
Category:   CMake
Reproducibility:always
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2013-06-28 10:04 EDT
Last Modified:  2013-06-28 10:04 EDT
== 
Summary:Add generators for Visual Studio 2013
Description: 
As Microsoft now has released a preview version of Visual Studio 2013,
generators for that IDE should be added to CMake.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-06-28 10:04 Petter 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] INTERFACE_LINK_LIBRARIES property?

[Stephen Kelly]

Brad King wrote:

>> I believe
>> 
>>  tll(tgt LINK_PRIVATE a LINK_PUBLIC b LINK_PRIVATE c)
>> 
>> is valid today. I can't think of a reason to want that
> 
> We considered such cases way back when first discussing that interface.
> The use case is that there is an ordered implementation dependency on
> "a;b;c" but only "b" should be in the link interface.

True. Added a unit test and pushed again to my clone. I'll wait until 
INTERFACE_LINK_LIBRARIES-prop is in master before merging it to next.

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

[cmake-developers] [CMake 0014252]: Unsupported "-arch x86_64" mysteriously ends up in Fortran_FLAGS

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=14252 
== 
Reported By:Mojca Miklavec
Assigned To:
== 
Project:CMake
Issue ID:   14252
Category:   (No Category)
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2013-06-28 09:13 EDT
Last Modified:  2013-06-28 09:13 EDT
== 
Summary:Unsupported "-arch x86_64" mysteriously ends up in
Fortran_FLAGS
Description: 
http://public.kitware.com/pipermail/cmake-developers/2013-January/006230.html

An unsupported compiler flag "-arch x86_64" mysteriously sneaks into
Fortran_FLAGS when
-DCMAKE_OSX_ARCHITECTURES="x86_64"
is passed to cmake. That flag CMAKE_OSX_ARCHITECTURES is added automatically to
all projects in MacPorts (third-party package manager for Mac OS X) even when
cross-compiling or compilation of fat binaries (like i386+x86_64) is not needed,
so no project that needs Fortran and CMake can be compiled (luckily there are
not many such projects, but it's still a showstopper to switch to CMake).


The g95 compiler ignores "-arch <...>" flag, but GCC's gfortran 4.x throws an
error and breaks compilation. I could probably try to prevent
DCMAKE_OSX_ARCHITECTURES from being passed to cmake (via some tricks in MacPorts
or by modifying MacPorts sources), but I still believe that passing "-arch
x86_64" to Fortran_FLAGS is a bug in CMake.


Steps to Reproduce: 
Compiled Root (root.cern.ch) or any minimal project which needs Fortran with

cmake \
-DCMAKE_Fortran_COMPILER=/opt/local/bin/gfortran-mp-4.5 \
-DCMAKE_C_COMPILER=/usr/bin/clang \
-DCMAKE_CXX_COMPILER=/usr/bin/clang++ \
-DCMAKE_INSTALL_PREFIX=/path/to/install \
-DCMAKE_OSX_ARCHITECTURES="x86_64" ../path/to/sources

In that particular project the generated file
misc/minicern/CMakeFiles/minicern.dir/flags.make
ends up containing the following variables (among others):
C_FLAGS =  -m64 -pipe -W -Wall -fsigned-char -fno-common -O2 -g-arch x86_64
-fPIC -I
Fortran_FLAGS =  -m64 -std=legacy -arch x86_64 -fPIC
-I

The flag "-arch x86_64" shouldn't be there.

Additional Information: 
Citing
http://public.kitware.com/pipermail/cmake-developers/2013-January/006230.html:

The "-arch" flag is hard-coded here:

 
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalGenerator.cxx;hb=v2.8.10.2#l1826

It was added to CMake way back when universal binary support was
first added to OS X under the assumption that all compilers that
would be used in combination with CMAKE_OSX_ARCHITECTURES would
support the flag.  Obviously the assumption is wrong.

The hard-coded flag needs to be replaced with a lookup of a new
per-language platform information variable, perhaps called

 CMAKE__OSX_ARCHITECTURE_FLAG

-Brad


Some more links:
- https://trac.macports.org/ticket/37732 (about the -arch flag in Fortran)
- https://trac.macports.org/ticket/37688 ([also] about development of a package
for Root using CMake)
- https://sft.its.cern.ch/jira/browse/ROOT-4874 (not strictly related)

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-06-28 09:13 Mojca Miklavec 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] Disallowing include() of export() result

[Stephen Kelly]

Brad King wrote:

> What about the APPEND mode of export?  Do you plan to try to
> collect all the appended pieces together, all delayed until
> generate time? 

Yes, that is the approach I took before, which is still available as 
5343c596db797f063300226069f219668d70a399 (Process the export() command at 
generate time.) in my clone.

Reading the commit again now, it looks like it would properly handle things 
like multiple namespaces:

 export(TARGETS foo NAMESPACE NS1 FILE theFile.cmake)
 export(TARGETS bar NAMESPACE NS2 APPEND FILE theFile.cmake)

> Perhaps the policy could also disallow the
> APPEND mode altogether.  IIRC I've participated in discussion
> in the past about how APPEND is a bad approach anyway.

I've never used it, but then I've never used export() except in unit tests 
of it either :). I don't think preserving the APPEND functionality is 
expensive.

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] GeneratorExpression test on VS 6 NMake

[Stephen Kelly]

Brad King wrote:

> Steve,
> 
> Please take a look at this failure:
> 
>  http://open.cdash.org/testDetails.php?test=196577461&build=2949683
>  expanded command line '...' too long
> 
> I think the GeneratorExpression test needs to be split into
> even more parts.
> 

Yep, that was expected eventually. Repushed the version-compare-genex doing 
that.

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] INTERFACE_LINK_LIBRARIES property?

[Brad King]

On 06/28/2013 08:42 AM, Stephen Kelly wrote:
> However, it should be only:
> 
>  target_link_libraries(   ...
>[  ...] ...])

Yes.

> I can change that so that all of the following are valid:
> 
>  tll(tgt PRIVATE a PUBLIC b INTERFACE c)
>  tll(tgt INTERFACE c PRIVATE a PUBLIC b)
>  tll(tgt INTERFACE c PUBLIC b PRIVATE a)
>  tll(tgt INTERFACE c PUBLIC b PRIVATE a PUBLIC d INTERFACE e)

Yes.  I think that will be the simplest to use.  Please be
sure that empty library lists in cases like

 tll(tgt PRIVATE a PUBLIC INTERFACE c)

work because they could come from

 tll(tgt PRIVATE a PUBLIC ${list_of_libs_maybe_empty} INTERFACE c)

> I believe 
> 
>  tll(tgt LINK_PRIVATE a LINK_PUBLIC b LINK_PRIVATE c)
> 
> is valid today. I can't think of a reason to want that

We considered such cases way back when first discussing that interface.
The use case is that there is an ordered implementation dependency on
"a;b;c" but only "b" should be in the link interface.

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] Disallowing include() of export() result

[Brad King]

On 06/28/2013 07:20 AM, Stephen Kelly wrote:
> I've pushed an export-policy topic to my clone which attempts to disallow 
> including the result of the export command. This is part of making it 
> possible to make export() be executed at generate time in the future.

Great!

> An alternative would be to add a new command generate_export() which takes 
> the same arguments, or a GENERATE keyword to the export() command, and 
> deprecate the existing export() signature with a policy. 

I prefer the policy so that we don't widen the interface further.
Inserting an extra "generate" on either side of the "(" will just
be noise after projects transition.

I think having the policy warning trigger on the basic (bad) use
case will be sufficient.  If projects run into more corner cases
then we can add warnings for them.

What about the APPEND mode of export?  Do you plan to try to
collect all the appended pieces together, all delayed until
generate time?  Perhaps the policy could also disallow the
APPEND mode altogether.  IIRC I've participated in discussion
in the past about how APPEND is a bad approach anyway.

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] INTERFACE_LINK_LIBRARIES property?

[Stephen Kelly]

Brad King wrote:

> So, if the first argument after the lhs is "LINK_PUBLIC"
> or "LINK_PRIVATE" then it is the existing signature, and if
> it is "PUBLIC" or "PRIVATE" or "INTERFACE" then it is the
> "new" signature, right?

Right. That's almost what is in my tll-new-signatures branch:

 target_link_libraries( INTERFACE  ...)

 target_link_libraries(   ...
   [  ...] ...])

However, it should be only:

 target_link_libraries(   ...
   [  ...] ...])

right?

I can change that so that all of the following are valid:

 tll(tgt PRIVATE a PUBLIC b INTERFACE c)
 tll(tgt INTERFACE c PRIVATE a PUBLIC b)
 tll(tgt INTERFACE c PUBLIC b PRIVATE a)
 tll(tgt INTERFACE c PUBLIC b PRIVATE a PUBLIC d INTERFACE e)

I believe 

 tll(tgt LINK_PRIVATE a LINK_PUBLIC b LINK_PRIVATE c)

is valid today. I can't think of a reason to want that, but I guess we 
shouldn't change it.

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

[cmake-developers] GeneratorExpression test on VS 6 NMake

[Brad King]

Steve,

Please take a look at this failure:

 http://open.cdash.org/testDetails.php?test=196577461&build=2949683
 expanded command line '...' too long

I think the GeneratorExpression test needs to be split into
even more parts.

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] INTERFACE_LINK_LIBRARIES property?

[Brad King]

On 06/28/2013 06:02 AM, Stephen Kelly wrote:
> Is it really worthwhile to introduce both INTERFACE and LINK_INTERFACE?

No, I forgot that "LINK_INTERFACE" does not exist.
It is fine to just add "INTERFACE".

> * LINK_PUBLIC is treated as an alias for PUBLIC 
> * LINK_PRIVATE is treated as an alias for PRIVATE

Yes, though see response below about mixing.

> * LINK_INTERFACE_LIBRARIES is *not* treated as an ALIAS for INTERFACE

Correct.  This one is different because it is a command mode,
not a keyword that can appear anywhere among other libraries.

> That would mean mixtures like this would be allowed:
> 
>  target_link_libraries(lhs LINK_PUBLIC a PRIVATE b)
> 
> Should they be?

I was thinking that at the time I sent the grandparent message
but now that I see an example spelled out I agree it looks
nicer to make them exclusive.  That will also be easier to
document because the list of signatures will not need something
like "" in it.

So, if the first argument after the lhs is "LINK_PUBLIC"
or "LINK_PRIVATE" then it is the existing signature, and if
it is "PUBLIC" or "PRIVATE" or "INTERFACE" then it is the
"new" signature, right?

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] Disallowing include() of export() result

[Stephen Kelly]

Hi,

I've pushed an export-policy topic to my clone which attempts to disallow 
including the result of the export command. This is part of making it 
possible to make export() be executed at generate time in the future.

There are limitations to my topic already. For example, it doesn't warn if 
someone uses file(APPEND) on the targets file, though that would be easy to 
add. It also doesn't warn if someone uses, for example, execute_process 
giving the targets file as an argument. That's something that can probably 
not be handled with a warning, and there are other similar cases. Is that 
acceptable, or is it better to not change this at all?

An alternative would be to add a new command generate_export() which takes 
the same arguments, or a GENERATE keyword to the export() command, and 
deprecate the existing export() signature with a policy. 

I think the new command may be a better idea.

Comments?

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] INTERFACE_LINK_LIBRARIES property?

[Stephen Kelly]

Brad King wrote:

> Okay, I think we've had some confusion due to differing assumptions
> about the meaning of "old" and "new" tll signatures.  Let me be more
> explicit.  For the signature policy, there are two groups of signatures:
> 
> * Group A (what I called "old" signatures):
> 
>   target_link_libraries(lhs a b c)
>   target_link_libraries(lhs LINK_INTERFACE_LIBRARIES a b c)
> 
> * Group B (what I called "new" signatures):
> 
>   target_link_libraries(lhs LINK_PUBLIC a LINK_PRIVATE b LINK_INTERFACE c)
>   target_link_libraries(lhs PUBLIC a PRIVATE b INTERFACE c)

Is it really worthwhile to introduce both INTERFACE and LINK_INTERFACE?

> The semantics of the two group B signatures are *identical*.  There
> is absolutely ZERO distinction between PUBLIC and LINK_PUBLIC.

Ok. So, 

* LINK_PUBLIC is treated as an alias for PUBLIC 
* LINK_PRIVATE is treated as an alias for PRIVATE
* LINK_INTERFACE_LIBRARIES is *not* treated as an ALIAS for INTERFACE

Correct?

> I expected to see things like
> 
> - else if(args[i] == "LINK_PUBLIC")
> + else if(args[i] == "PUBLIC" || args[i] == "LINK_PUBLIC")

That would mean mixtures like this would be allowed:

 target_link_libraries(lhs LINK_PUBLIC a PRIVATE b)

Should they be?

> Now, the signature policy should have the following behavior:
> 
> * OLD: Group A *and* group B can be used for one lhs
> * NEW: Group A *xor* group B can be used for one lhs

Right.

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

[cmake-developers] [CMake 0014251]: VS2013 Support

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14251 
== 
Reported By:Minmin Gong
Assigned To:
== 
Project:CMake
Issue ID:   14251
Category:   CMake
Reproducibility:always
Severity:   block
Priority:   normal
Status: new
== 
Date Submitted: 2013-06-28 05:14 EDT
Last Modified:  2013-06-28 05:14 EDT
== 
Summary:VS2013 Support
Description: 
VS2013 preview is released. But cmake doesn't have a generator for it.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-06-28 05:14 Minmin GongNew 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