Re: [cmake-developers] [ANNOUNCE] cmake-unit - A new unit testing framework for CMake

[Brad King]

On 01/25/2016 11:01 AM, Sam Spilsbury wrote:
> Over the last two years I've been working on a new unit testing
> framework for CMake. I started this project because I've been writing
> some other fairly complex CMake modules and I kept making mistakes
> which would take me hours to debug weeks down the line.
> 
> The project is, rather unimaginatively, called cmake-unit. The key
> difference between this and the RunCMake framework that's used by
> CMake internally is that cmake-unit more closely resembles an xUnit
> architecture. It has support for a generic assert_that function and
> matchers, test-case autodiscovery, coverage report generation and
> allows you to keep all your tests together in a single file. The only
> downside so far is that it runs a fair bit slower than RunCMake does.

Nice.  I think if something like this were to be provided by upstream
CMake it would be better to implement it directly in C++, at least for
the test execution and output matching parts.  That would be much faster
than a pure CMake language implementation and also would not need hacks
to execute CMake language functions.

One of the weaknesses of RunCMake infrastructure is that the CMake regex
engine is not meant for large expressions.  For example, the number of
()-groups is limited to 10 or so.  It is also not as expressive as
modern regex implementations offer.  There has been discussion about
replacing the regex engine previously:

 https://cmake.org/pipermail/cmake-developers/2011-November/014249.html

but there are major compatibility challenges:

 https://cmake.org/pipermail/cmake-developers/2011-November/014376.html

OTOH in a brand new interface we could use an alternate regex engine
from the beginning.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0015941]: file glob case sensitivity depends on platform

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15941 
== 
Reported By:hegewald
Assigned To:
== 
Project:CMake
Issue ID:   15941
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-29 05:05 EST
Last Modified:  2016-01-29 05:05 EST
== 
Summary:file glob case sensitivity depends on platform
Description: 
[The OS did not fit in the above field, so here is the full version:
Mac OS 10.11.3 / SUSE Linux Enterprise Server 11 (x86_64)]

Cmakes file glob returns files regardless of the case used in the glob
expression on Mac OS (even on a case sensitive filesystem). On Linux glob
returns the files which match the case being used in the expression, as would be
returned by the ls terminal command.

Steps to Reproduce: 
Have two files where the suffix differs in case, use cmake file glob with on of
the cases used in a suffix.
Example:
# directory
src/
  foo.f90
  bar.F90

# ls on Mac
ls src/*.F*
bar.F90

# cmake on Mac
file(GLOB all_sources ${src}/*.F*
message(STATUS "all_sources: ${all_sources}")
-- all_sources: /.../src/bar.F90;/.../src/foo.f90

# ls on Linux
ls src/*.F*
bar.F90

# cmake on Linus
file(GLOB all_sources ${src}/*.F*
message(STATUS "all_sources: ${all_sources}")
-- all_sources: /.../src/bar.F90
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-29 05:05 hegewald   New Issue
2016-01-29 05:05 hegewald   File Added: CMakeLists.txt
==

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0015943]: CMAKE_CXX_STANDARD not working on non-apple clang++

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15943 
== 
Reported By:senz
Assigned To:
== 
Project:CMake
Issue ID:   15943
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   high
Status: new
== 
Date Submitted: 2016-01-29 12:24 EST
Last Modified:  2016-01-29 12:24 EST
== 
Summary:CMAKE_CXX_STANDARD not working on non-apple clang++
Description: 
cmake does not set standard related flags on non-apple clang++ ignoring
CMAKE_CXX_STANDARD var or/and CXX_STANDARD propery.

Steps to Reproduce: 
# brew install llvm --with-clang --with-libcxx --with-rtti
# export PATH=/usr/local/opt/llvm/bin:$PATH
# export CXX=/usr/local/opt/llvm/bin/clang++
# export CC=/usr/local/opt/llvm/bin/clang

cmake project with
set (CMAKE_CXX_STANDARD 14)
set (CMAKE_CXX_STANDARD_REQUIRED ON)

# make VERBOSE=1
no -std=c++14 flag
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-29 12:24 senz   New Issue
==

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0015944]: Use after free in regexp functionality

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15944 
== 
Reported By:hanno
Assigned To:
== 
Project:CMake
Issue ID:   15944
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-29 13:10 EST
Last Modified:  2016-01-29 13:10 EST
== 
Summary:Use after free in regexp functionality
Description: 
The attached file will cause a use after free error in cmake. This is a reduced
example, I originally discovered this by using a version of cmake built with
address sanitizer.

This bug can also be seen by using cmake with valgrind (but the asan output is
more detailed).

Steps to Reproduce: 
1. run "cmake ." in a directory with the attached file. cmake must either be
compiled with address sanitizer or run with valgrind.

Additional Information: 
Here's the significant part of the asan error:

==10481==ERROR: AddressSanitizer: heap-use-after-free on address 0x60314998
at pc 0x7f7f52711590 bp 0x7ffedc5d4690 sp 0x7ffedc5d4660
READ of size 2 at 0x60314998 thread T0
https://public.kitware.com/Bug/view.php?id=0 0x7f7f5271158f in
__interceptor_strchr
(/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libasan.so.1+0x3458f)
https://public.kitware.com/Bug/view.php?id=1 0x564b27c3891b in strchr
/usr/include/string.h:226
https://public.kitware.com/Bug/view.php?id=2 0x564b27c3891b in
cmsys::RegularExpression::find(char const*)
/var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/kwsys/RegularExpression.cxx:928
https://public.kitware.com/Bug/view.php?id=3 0x564b278c9f7e in
cmConditionEvaluator::HandleLevel2(std::list&, std::string&, cmake::MessageType&)
/var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmConditionEvaluator.cxx:608
https://public.kitware.com/Bug/view.php?id=4 0x564b278decd8 in
cmConditionEvaluator::IsTrue(std::vector const&, std::string&,
cmake::MessageType&)
/var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmConditionEvaluator.cxx:78
https://public.kitware.com/Bug/view.php?id=5 0x564b278df3a0 in
cmIfCommand::InvokeInitialPass(std::vector const&, cmExecutionStatus&)
/var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmIfCommand.cxx:217
https://public.kitware.com/Bug/view.php?id=6 0x564b276bb068 in
cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&)
/var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmMakefile.cxx:305
https://public.kitware.com/Bug/view.php?id=7 0x564b276bb7d2 in
cmMakefile::ReadListFile(cmListFile const&, std::string const&)
/var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmMakefile.cxx:611
https://public.kitware.com/Bug/view.php?id=8 0x564b276bd3a6 in
cmMakefile::Configure()
/var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmMakefile.cxx:1663
https://public.kitware.com/Bug/view.php?id=9 0x564b27aa5ec3 in
cmGlobalGenerator::Configure()
/var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmGlobalGenerator.cxx:1126
https://public.kitware.com/Bug/view.php?id=10 0x564b27ac9241 in
cmGlobalUnixMakefileGenerator3::Configure()
/var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmGlobalUnixMakefileGenerator3.cxx:133
https://public.kitware.com/Bug/view.php?id=11 0x564b2779ed6b in
cmake::ActualConfigure()
/var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmake.cxx:1422
https://public.kitware.com/Bug/view.php?id=12 0x564b277a0248 in
cmake::Configure()
/var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmake.cxx:1205
https://public.kitware.com/Bug/view.php?id=13 0x564b277a51f7 in
cmake::Run(std::vector const&, bool)
/var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmake.cxx:1579
https://public.kitware.com/Bug/view.php?id=14 0x564b2763f2f9 in
do_cmake(int, char const* const*)
/var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmakemain.cxx:330
https://public.kitware.com/Bug/view.php?id=15 0x564b2763751a in main
/var/tmp/portage/dev-util/cmake-3.4.3/work/cmake-3.4.3/Source/cmakemain.cxx:190
https://public.kitware.com/Bug/view.php?id=16 0x7f7f511b062f in
__libc_start_main (/lib64/libc.so.6+0x2062f)
https://public.kitware.com/Bug/view.php?id=17 0x564b2763ce78 in _start
(/usr/bin/cmake+0x163e78)

[cmake-developers] Patch: Remove superfluous semicolon after method

[Christoph Grüninger]

Dear CMake devs,
please find attached a minimal patch to fix a GCC 6 pedantic warning
concerning a superfluous semicolon after a method.

Additional I got the following warning:
> CMake/Source/cmGeneratorTarget.cxx:4835:52: warning: format ‘%u’ expects 
> argument of type ‘unsigned int*’, but argument 3 has type ‘int*’ [-Wformat=]
>sscanf(config_reps, "%u", );

Same on 4840:45, 5543:51, 5548:44 in the same file. It is not obvious to
me whether you want to change the types in cmOptionalLinkInterface,
change the type in sscanf or cast the types.

Bye
Christoph
>From be4d8226d4f34d0cbf18b1a08b0e187e577edc38 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christoph=20Gr=C3=BCninger?= 
Date: Fri, 29 Jan 2016 22:16:03 +0100
Subject: [PATCH] cmAlgorithms.h: remove superfluous semicolon after method

---
 Source/cmAlgorithms.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Source/cmAlgorithms.h b/Source/cmAlgorithms.h
index 54617f3..bb65ea5 100644
--- a/Source/cmAlgorithms.h
+++ b/Source/cmAlgorithms.h
@@ -230,7 +230,7 @@ template
 std::string cmJoin(Range const& r, std::string delimiter)
 {
   return cmJoin(r, delimiter.c_str());
-};
+}
 
 template
 typename Range::const_iterator cmRemoveN(Range& r, size_t n)
-- 
2.6.2

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [ANNOUNCE] cmake-unit - A new unit testing framework for CMake

[Eric Wing]

On 1/29/16, Brad King  wrote:
> On 01/25/2016 11:01 AM, Sam Spilsbury wrote:
>> Over the last two years I've been working on a new unit testing
>> framework for CMake. I started this project because I've been writing
>> some other fairly complex CMake modules and I kept making mistakes
>> which would take me hours to debug weeks down the line.
>>
>> The project is, rather unimaginatively, called cmake-unit. The key
>> difference between this and the RunCMake framework that's used by
>> CMake internally is that cmake-unit more closely resembles an xUnit
>> architecture. It has support for a generic assert_that function and
>> matchers, test-case autodiscovery, coverage report generation and
>> allows you to keep all your tests together in a single file. The only
>> downside so far is that it runs a fair bit slower than RunCMake does.
>
> Nice.  I think if something like this were to be provided by upstream
> CMake it would be better to implement it directly in C++, at least for
> the test execution and output matching parts.  That would be much faster
> than a pure CMake language implementation and also would not need hacks
> to execute CMake language functions.
>
> One of the weaknesses of RunCMake infrastructure is that the CMake regex
> engine is not meant for large expressions.  For example, the number of
> ()-groups is limited to 10 or so.  It is also not as expressive as
> modern regex implementations offer.  There has been discussion about
> replacing the regex engine previously:
>
>  https://cmake.org/pipermail/cmake-developers/2011-November/014249.html
>
> but there are major compatibility challenges:
>
>  https://cmake.org/pipermail/cmake-developers/2011-November/014376.html
>
> OTOH in a brand new interface we could use an alternate regex engine
> from the beginning.
>
> -Brad
>

Just a random thought on the regex issue since we were talking about
Lua in the other thread. Not saying this is the way to go, but
something worth knowing about.

Lua has a library called LPeg, which was created by the Lua authors
themselves. It is basically academically rigorous rethink of the regex
problem.

There is a good presentation of it here:
https://vimeo.com/1485123

But in a nutshell, "RegEx" (distinct for Computer Science notion of
regular expressions) are a hack because they leave the domain of CS
and what can be understood/proven about computability. This results in
implementation dependent, unpredictable performance costs for RegEx
with no mathematical grounding. And a lot of the features bolted on to
RegEx have odd behaviors and limitations that can be
surprising/frustrating. Lua thought about this problem not only
because the lack of elegance, but also because PCRE implementations
are huge...much larger than Lua itself.

So they turned to old research on something called PEGs (Parseable
Expression Grammars). They are akin to Context Free Grammars...drawing
the analogy that CFGs are one up the computability ladder from regular
expressions. This allows PEGs to capture more complicated/expressive
things that RegEx has been abused to try to handle. (Some examples are
in the video.)

I'm by no means an LPeg expert, but I had one project where I had to
do Android package name validation, which follows the rules of Java
language package names. LPeg comes with a convenience layer called
"re" (which might stand for regular expression...haven't thought if
they mean in the 'pure' sense), which allows you to write your
patterns in something that resembles BNF grammars. It was a real
delight because suddenly everything was really clear and readable. (I
have a Perl background so I'm very used to crazy RegEx.)

Anyway, I figure one reason CMake doesn't already have a full blown
PCRE engine is because of the size and complexity. (I know SWIG
doesn't include PCRE for some reason and encourages you to download it
separately and conditionally compiles (disabling features) based on
whether you have it or not.) So this might be another be another angle
to look at if a Lua effort is serious. (Timing will be a problem
because I suspect the Lua thing is pretty far off. But this is another
angle to consider about what we would want a Lua engine to do for
CMake.) Last I checked, my built LPeg binary was under 50k.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0015945]: "Target Platform Version" Option in Visual Sutio 2015

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15945 
== 
Reported By:Gehua Yang
Assigned To:
== 
Project:CMake
Issue ID:   15945
Category:   (No Category)
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-29 13:51 EST
Last Modified:  2016-01-29 13:51 EST
== 
Summary:"Target Platform Version" Option in Visual Sutio
2015
Description: 
I am trying to compile code and generate binaries that's compatible with Windows
7/8/8.1.  Following MSDN's suggestion, I can set "Target Platform Version" under
the General tag to use SDK 8.1, which works fine for me (see screenshot).  The
real problem is this change is not preserved after a CMake run.  

This issue is very similar to Issue https://cmake.org/Bug/view.php?id=15686 and
Issue https://cmake.org/Bug/view.php?id=15670.  I read through the report under
both and learned that one can use CMAKE_SYSTEM_VERSION to change the "Target
Platform Version" value across all projects in a VS solution.  

Perhaps it is not a bug and simply caused by not doing things right. But I
cannot find any more documentation related to this on web. My apology in
advance! 
However, I tried to do that with CMake 3.4.3 (latest release from cmake.org),
but the projects generated does not contain this TargetPlatformVersion tag and
hence its value is still defaulted to 10.0.10240.0.

Steps to Reproduce: 
1. In CMake GUI, set CMAKE_SYSTEM_VERSION to "8.1". Finish Cmake.  
2. Open Visual Studio 2015 and open the property page of any project. 
3. Go to "General" tab. 



Additional Information: 
Related to Issue https://cmake.org/Bug/view.php?id=15686 and Issue
https://cmake.org/Bug/view.php?id=15670
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-29 13:51 Gehua Yang New Issue
2016-01-29 13:51 Gehua Yang File Added: t.png
==

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

On 1/20/16, Brad King  wrote:
> On 01/20/2016 08:48 AM, Eric Wing wrote:
>> I thought maybe setting the internal
>> CMAKE_${lang}_COMPILER_ID_FLAGS_LIST or
>> CMAKE_${lang}_COMPILER_ID_FLAGS
>> to "-version" would fix this.
>>
>> But this did nothing.
>
> Those are internal details of the CMAKE_DETERMINE_COMPILER_ID
> function and are not meant to be set anywhere else.  I think you
> may be looking for something like this:
>
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineFortranCompiler.cmake;hb=v3.4.2#l122
>
> It is used by the CMAKE_DETERMINE_COMPILER_ID_VENDOR fallback when
> the compiler id cannot be extracted from the basic compiler output.
> More work may be needed to also extract a version number through
> the CMAKE_DETERMINE_COMPILER_ID_VENDOR infrastructure.

I need more guidance here. I'm not connecting the dots.
My problem seems to be that the execute_process() in
CMakeDetermineCompilerId.cmake is trying to invoke the command:
'swift CompilerId/main.swift'

This will cause swift to run in REPL mode which won't return.
It is not passing any of the flags I taught CMake to use when trying
to compile a Swift program.

Looking at the execute_process() that gets invoked (final one in the
big if/elseif block of CMAKE_DETERMINE_COMPILER_ID_BUILD), the only
way to get the flags I need are via CMAKE_${lang}_COMPILER_ID_FLAGS.
But there is a block at the top of the file which overwrites the
variables. I was suggesting list(APPEND) instead of set() would fix
that problem, and in fact look suspicious to me since there is no way
to access those values passed to execute_process().

  if(CMAKE_${lang}_FLAGS)
#set(CMAKE_${lang}_COMPILER_ID_FLAGS ${CMAKE_${lang}_FLAGS})
list(APPEND CMAKE_${lang}_COMPILER_ID_FLAGS ${CMAKE_${lang}_FLAGS})
  else()
#set(CMAKE_${lang}_COMPILER_ID_FLAGS $ENV{${flagvar}})
list(APPEND CMAKE_${lang}_COMPILER_ID_FLAGS $ENV{${flagvar}})
  endif()



>
> Yes.  One remaining question is if there is an established convention
> already out there for the name of the SWIFTFLAGS environment variable.
>

I haven't spotted anything so far. Remember that Xcode and anything
GUI based on Mac doesn't use environmental variables. So this isn't a
feature that the existing Apple community would be using.


Thanks,
Eric
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0015946]: "xcodebuild -target foo install" should do something sensible

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15946 
== 
Reported By:Dan Kegel
Assigned To:
== 
Project:CMake
Issue ID:   15946
Category:   CMake
Reproducibility:always
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-29 15:56 EST
Last Modified:  2016-01-29 15:56 EST
== 
Summary:"xcodebuild -target foo install" should do something
sensible
Description: 
xcode users expect to be able to use the 'install' buildaction with their
targets, but cmake's xcode generator makes install a target rather than a
buildaction.

It might make casual users happier if the xcode generator arranged for
   xcodebuild -target foo install
to the same thing as
   xcodebuild -target install

even if it were a bit of a kludge, as it would reduce need to RTFM in the common
case.

Additional Information: 
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/xcodebuild.1.html
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-29 15:56 Dan Kegel  New Issue
==

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language

[Eric Wing]

Just to answer some of your questions on this...



>
> I think the first step is design brainstorming and discussion to see if
> we can find something acceptable.
>
> IIRC one problem with earlier attempts at introducing Lua was that CMake's
> dynamic scoping is difficult to reconcile with Lua's lexical scoping.  Lua
> cannot be given direct access to CMake variable scopes because Lua data
> structures may outlive the CMake dynamic scopes, leading to dangling
> references.

I don't have a good solution for this. I think the original CMake/Lua
bridge was basically a 1-to-1 API mapping with the CMake API. So the
idea was anything you do in native Lua lives in your Lua state
following the standard Lua lifecycles of things, but communicating
with CMake required going through the CMake public API (via
functions/macros via Lua bindings to the API). For global variables, I
think there was a special Lua table for CMake globals which had a
metamethod which did something similar to set the CMake values.

Thus, I can't remember if there were any dangling data structures. I
think about ADD_LIBRARY or ADD_EXECUTABLE which essentially returns a
TARGET object which has a lifecycle. When returned to Lua, we wrap it
in a userdata. The wrapper could lose its scope and the wrapper could
get garbage collected. But the backend doesn't need to actually
collect or destroy the object so CMake can still manage the resource
itself.

An aside though, I do find the scoping and lifetime rules of CMake
very difficult to work with. I feel like I still don't have a good
intuition or understanding of when many things happen in CMake. Since
we use CMake to compile C/C++/etc which are lexical scoping, I find
this to be challenging, especially since I don't really want to be
focusing on details like this when I'm just trying to get my program
compiled. So figuring out how to better embrace (Lua's) lexical
scoping moving forward might be a win.


> I'd also prefer an approach that allows us to offer newer versions of Lua
> as they come out while still processing old scripts unchanged.  This means
> that all Lua code must lie in a context where CMake knows the version of
> Lua for which it was written.  I'd like to retain the possibility of
> supporting multiple Lua versions to allow future such version transitions.
> (Implementation symbols can be mangled to support multiple versions linked
> in one program.)

This should be possible, though it's not a topic I've carefully
followed myself. I think simply mangling all the API functions
differently should prevent any conflicts. (I don't think Lua has any
global/static shared state internally which avoids those problems.)

I should also point out though that if you are going to support
multiple simultaneous versions of Lua, things could get messy if the
user needs Lua state preserved across multiple calls (i.e. not a
purely functional design). So what happens if the user starts in Lua
5.3 and creates some data, but then calls a script that only works in
Lua 5.1. The VMs can't be mixed.


>
>   cmake_lua( [LOCAL ...] CODE ...)
>
> The  must be "5.2", the Lua language version.

One thing to keep in mind is that for at least Lua 5, most of the
scripting side changes have been pretty minor. Most of the time,
script authors figure out how to write a script that runs across all
versions of Lua 5. So specifying a list of supported versions may be
desirable.




>   number: value is interpreted as a decimal representation of
>   a floating point value to be stored in a Lua number.

One interesting introduction to Lua 5.3 (already out) is integer
subtypes in Lua, so it now has separate float and integer types if
useful.


>
> set(deg 90)
> cmake_lua(5.2 LOCAL number{deg} CODE [[
>   return { sin = math.sin(deg*math.pi) }]])
> message("sin(${deg}') = ${sin}')
>

So I personally imagined writing much bigger chunks in Lua directly
and directly invoking CMake APIs (via bindings, sort of like the
prototype). Not that I disagree with anything here. But I think for my
use case, the time I need Lua the most is for complicated code that is
really unwieldily in the native CMake language, not for little things.

For example, one of the worst parts of CMake code I have right now in
my current project is I need to track all the resource files
(separated into types like images, scripts, dynamic libraries,
plugins) in my project and retain the relative directory hierarchy for
everything so I can reconstruct them in the application
packaging/bundling process (a custom step I have as part of the build)
preserving the layout (but with platform aware adjustments as needed).
Basically, I wanted multi-dimensioned tables, but I don't get those in
CMake, so I'm doing really painful things with global strings and
appending key names to strings to make new unique string lists. It is
a beast of a system right now because so many things have to use it
and the key names are often done with variables there are a lot of