Re: [cmake-developers] Add command line options for deprecation message control

[Brad King]

On 09/19/2015 06:32 PM, Michael Scott wrote:
> whether the -W options are intended to only be applicable
> for the message command (and so the current behaviour is correct),
> or whether they should affect all author and deprecated messages
> output by other parts of CMake?

The -Wdev/-Wno-dev options have always been for all messages
output by any part of CMake.  This needs to be preserved/corrected.

> If the current behaviour isn't correct, then one thing to have a
> good think about, is how to handle turning warnings into errors
> when -Werr-dev or -Werr-deprecated (and also the required behaviour
> when -Wno- is used). As some users of IssueMessage do different
> things if an error occurs (and is output), *after* IssueMessage
> is called. So there might need to be a way to signal to the caller
> when a warning has been upgraded to an error because of the users
> options perhaps?

Likely yes.  This may require sweeping changes to address.  We're
too close to the freeze for 3.4 to do this now.  Perhaps we should
simply remove -Werr-dev for now.

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

Re: [cmake-developers] CPack/NSIS is broken after extended length paths fix

[Clinton Stimpson]

On Monday, September 21, 2015 12:28:37 PM Dmitry Kochkin wrote:
>  Hi Clint,
> 
> >>Actually it's even worse because in current master HEAD I can see that
> >>INST_DIR is empty in generated project: !define INST_DIR ""
> >>(not sure if that's caused by your change)
> >
> >Interesting... Do you know why this happens?  How is this problem related
> >to extended paths (with the \\?\ prefix)?  Do you have an example to
> >demonstrate this problem? That was my mistake, please ignore.>
> >>I've figured out that NSIS was not going to fix this (see 
> >>http://sourceforge.net/p/nsis/feature-requests/241/ )>
> >Maybe they'll accept a patch to fix it there?  Was there any effort to fix
> >it there?
> In the URL I've put they claim you should just use "\\?\" in your NSIS
> project. I guess it's also possible to fix NSIS, but we cannot rely that
> user have latest NSIS.

Using "\\?\" in a NSIS project is a workaround, not a fix.
If a workaround is put into CMake, then you are relying on the latest CMake, 
right?


> >>I've made a small patch to NSIS generator and template to put infamous
> >>\\?\ there.
> >>
> >>I can send directly to you as I guess you know more about these parts of
> >>code.>
> >You can send your patch to this mailing list for review.
> 
> Patch attached. It's a bit hacky, more fixing symptoms I guess. The purpose
> is only to demonstrate the idea. Let me know if it can be done in better
> way.

Yes, it fixes symptoms.  The correct and robust way to fix this is to fix NSIS.

I have concerns with this patch:

1. Are the paths cleaned before placed into the NSIS template?  Only clean 
paths can be prepended with \\?\.  For example, these paths may not contain 
"." or "../" in them.

2. This patch can break UNC paths.  UNC paths must be prepended with a "\\?
\UNC\" prefix instead of "\\?\".  If CPACK_TEMPORARY_DIRECTORY is a UNC path, 
this patch breaks it.

3. For the uninstall code put into the NSIS template, how do you know whether 
INSTDIR is a UNC path or not?  INSTDIR is determined by the end-user when 
installing the software.  Blindly prepending "\\?\" may not work all the time.

Clint
-- 

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 0015753]: CMake cannot detect changes in nested header files when using '-iquote'

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15753 
== 
Reported By:danilcha
Assigned To:
== 
Project:CMake
Issue ID:   15753
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2015-09-21 08:49 EDT
Last Modified:  2015-09-21 08:49 EDT
== 
Summary:CMake cannot detect changes in nested header files
when using '-iquote'
Description: 
Create a new project with such CMakeLists.txt:

cmake_minimum_required(VERSION 3.3)
project(test)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -iquote ${CMAKE_CURRENT_SOURCE_DIR}")
add_executable(test-iquote main.cpp dir/1.h dir/2.h)

And such structure:

CMakeLists.txt
Main.cpp  (contains #include "dir/1.h")
dir\
1.h   (contains #include "dir/2.h")
2.h

Build. Then modify 2.h. Build again. Nothing will happen, it will just say
'[100%] Built target test-iquote'. 

Additional Information: 
Tried with both clang and GCC. GNU Make 3.81.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-09-21 08:49 danilcha   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] generator expression for path slash conversion

[Kislinskiy, Stefan]

Ah, thank you very much! I was confused as the distinction between WIN32 and 
UNIX worked nevertheless.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Montag, 21. September 2015 16:17
To: Kislinskiy, Stefan
Cc: CHEVRIER, Marc; cmake-developers@cmake.org; James Johnston
Subject: Re: [cmake-developers] generator expression for path slash conversion

On 09/21/2015 10:05 AM, Kislinskiy, Stefan wrote:
> if(MSYS)
>   check(test_shell_path "/c/shell/path")
> elseif(WIN32)
>   check(test_shell_path "c:shellpath")
> elseif(UNIX)
>   check(test_shell_path "c:/shell/path")
> endif()
> 
> No matter what I'm doing, it always ends up in the WIN32 branch with 
> FORWARD slashes. Additionally the drive letter is NOT converted to a posix 
> path as it should be the case for MSYS. I tried MSYS from the official MinGW 
> package, and I tried the MSYS2 installer. In both cases I called cmake from 
> MinGW-sh, MSYS-sh, and even cmd.exe. I used the "MSYS Makefiles" Generator. 
> In addition I tried the "MinGW Makefiles" generator just to check if 
> "if(MINGW)" is working... which also fails. The configuring/generating itself 
> is working.. Any ideas?

The code in the check-part4.cmake script runs in a cmake script (via "cmake 
-P").  That does not have any information about the configuration of the 
project, generator used, or target platform.
If you need this information it needs to be passed in through additional 
"-Dvar=val" arguments prior to the -P argument.

-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

Re: [cmake-developers] Generator expressions for install destination

[Brad King]

On 09/18/2015 03:49 PM, Robert Goulet wrote:
> Here's a version that is more conservative. It doesn't change
> the install(EXPORT) behavior.

> install(TARGET) already supported genex

Right.  I'd forgotten about these changes:

 install: Allow generator expressions in TARGETS DESTINATION (#14317)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f30022eb
 http://www.cmake.org/Bug/view.php?id=14317#c37959

>, so basically this patch adds install(FILES) destination genex.

Okay.  I see many hunks of this form:

> -   this->Destination,
> +   this->GetDestination(),

Making the Destination member private and moving GetDestination()
back into cmInstallGenerator is refactoring that should be split
out into its own commit.  Note that GetDestination() was removed
from the base class here:

 cmInstallGenerator: Move GetDestination to subclasses that need it
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f1db

Restoring it will need a justification in the commit message.
I'm concerned about having both overloads avilable:

> +  std::string GetDestination() const;
> +  std::string GetDestination(std::string const& config) const;

when only one is safe to call from each subclass.  This is why the
above-linked commit removed the method from cmInstallGenerator in
favor of having the needed overload in each subclass.

> -  cmInstallGenerator(const char* destination,
> +  cmInstallGenerator(cmMakefile* mf,
> + const char* destination,

This and its related changes are also refactoring that should go
in its own commit.

> +  // We need per-config actions if destination have generator expressions.
> +  if(cmGeneratorExpression::Find(Destination) != std::string::npos)
> +{
> +this->ActionsPerConfig = true;
> +}

Was this the solution to the availability of a configuration for
calls to GetDestination()?

> Perhaps we should update the Help to only mention install(FILES)
> destination instead of all variations of install?

Yes, the actual availability of the behavior should be documented.

Also please look at making the test suite actually verify that
the installation works as expected.  The above-linked commit
f30022eb adds a test that fails if generator expressions are
not evaluated to the correct values.

Thanks,
-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 0015755]: add_dependencies() undoes include_directories()

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15755 
== 
Reported By:Dimitri Merejkowsky
Assigned To:
== 
Project:CMake
Issue ID:   15755
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2015-09-21 12:27 EDT
Last Modified:  2015-09-21 12:27 EDT
== 
Summary:add_dependencies() undoes include_directories()
Description: 
Calling add_dependencies() between two targets causes some calls to
include_directories() to no longer be taken into account

Steps to Reproduce: 
See attached project.

$ mkdir b1
$ cmake ..
$ make
...
[ 25%] Linking C executable eggs
CMakeFiles/eggs.dir/eggs.c.o: In function `main':
eggs.c:(.text+0xa): undefined reference to `spam

$ mkdir b2
$ cmake -DADD_DEPENDENCIES=ON ..
$ make
[ 25%] Building C object spam/CMakeFiles/spam.dir/src/spam.c.o
spam/src/spam.c:1:23: fatal error: spam/spam.h: No such file or directory

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-09-21 12:27 Dimitri MerejkowskyNew Issue   

2015-09-21 12:27 Dimitri MerejkowskyFile Added: spam.zip

==

-- 

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] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version

[Brad King]

On 09/18/2015 02:24 PM, Brad King wrote:
> After working out the support for manifests across all generators
> as discussed elsewhere in this thread, I've added your manifest
> file to CMake's own build:
> 
>  Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674)
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdd15551

That broke the build of cmake-gui due to an incorrect relative path
to the manifest file.  I've revised the commit accordingly:

 Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=17009189

-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

Re: [cmake-developers] generator expression for path slash conversion

[Kislinskiy, Stefan]

I wrote the documentation and extended the GeneratorExpression tests for the 
SHELL_PATH genex. It works fine for WIN32 and UNIX. However, I'm having some 
trouble to test for MSYS. The check looks like:

if(MSYS)
  check(test_shell_path "/c/shell/path")
elseif(WIN32)
  check(test_shell_path "c:shellpath")
elseif(UNIX)
  check(test_shell_path "c:/shell/path")
endif()

No matter what I'm doing, it always ends up in the WIN32 branch with FORWARD 
slashes. Additionally the drive letter is NOT converted to a posix path as it 
should be the case for MSYS. I tried MSYS from the official MinGW package, and 
I tried the MSYS2 installer. In both cases I called cmake from MinGW-sh, 
MSYS-sh, and even cmd.exe. I used the "MSYS Makefiles" Generator. In addition I 
tried the "MinGW Makefiles" generator just to check if "if(MINGW)" is 
working... which also fails. The configuring/generating itself is working.. Any 
ideas?

Stefan

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Donnerstag, 17. September 2015 15:56
To: Kislinskiy, Stefan
Cc: CHEVRIER, Marc; cmake-developers@cmake.org; James Johnston
Subject: Re: [cmake-developers] generator expression for path slash conversion

On 09/17/2015 09:51 AM, Kislinskiy, Stefan wrote:
> I wrote a SHELL_PATH genex which uses
> cmOutputConverter->ConvertToOutputFormat(..., SHELL) for the conversion.
> I decided to name the genex SHELL_PATH instead of TO_SHELL_PATH for 
> the sake of consistency to other genexes like LOWER_CASE. What do you think?

LGTM.

> I would write some documentation as well of course.

Yes, please.  Also please look at extending the test suite to cover it.
See Tests/GeneratorExpression for genex unit test examples.  If possible we 
should also have a case that uses it in practice in a way that fails on 
invocation of an actual native tool if the slashes are wrong.  That will 
confirm not only that the genex does what we expect but that it also solves the 
problem we're trying to solve.

Thanks,
-Brad



shell_path_genex_v2.patch
Description: shell_path_genex_v2.patch
-- 

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] generator expression for path slash conversion

[Brad King]

On 09/21/2015 10:05 AM, Kislinskiy, Stefan wrote:
> if(MSYS)
>   check(test_shell_path "/c/shell/path")
> elseif(WIN32)
>   check(test_shell_path "c:shellpath")
> elseif(UNIX)
>   check(test_shell_path "c:/shell/path")
> endif()
> 
> No matter what I'm doing, it always ends up in the WIN32 branch
> with FORWARD slashes. Additionally the drive letter is NOT converted to a 
> posix path as it should be the case for MSYS. I tried MSYS from the official 
> MinGW package, and I tried the MSYS2 installer. In both cases I called cmake 
> from MinGW-sh, MSYS-sh, and even cmd.exe. I used the "MSYS Makefiles" 
> Generator. In addition I tried the "MinGW Makefiles" generator just to check 
> if "if(MINGW)" is working... which also fails. The configuring/generating 
> itself is working.. Any ideas?

The code in the check-part4.cmake script runs in a cmake script
(via "cmake -P").  That does not have any information about the
configuration of the project, generator used, or target platform.
If you need this information it needs to be passed in through
additional "-Dvar=val" arguments prior to the -P argument.

-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

Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version

[Brad King]

On 09/18/2015 02:58 PM, James Johnston wrote:
> While on the subject, there are some other additions to the manifest you
> might want to consider.

I think these are worth considering but we're too close to the 3.4 freeze
to make these changes now.  Please look at adding these during post-3.4
development.

Thanks,
-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 0015754]: Visual Studio incremental build not working properly when target names start with a capital letter

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15754 
== 
Reported By:Johannes Asal
Assigned To:
== 
Project:CMake
Issue ID:   15754
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2015-09-21 10:54 EDT
Last Modified:  2015-09-21 10:54 EDT
== 
Summary:Visual Studio incremental build not working properly
when target names start with a capital letter
Description: 
When using a target name starting with a capital letter (e.g. Mylibrary) in
add_library (and probably also add_executable), GCC toolchains build fine but
Visual Studio (tested with 2010 specifically) refuses to compile new .cpp files
in the first incremental build after adding them to the CMakeLists.txt. However,
it correctly detects that the CMakeLists.txt has changed and reconfigures
accordingly. The second incremental build compiles the added files, which makes
it even more strange. Please note that the bug occurs only when building via the
CMake command line interface (cmake.exe --build). Building from within Visual
Studio works always which is why I think it must be a problem with CMake.

Steps to Reproduce: 
Install Visual Studio 2010. Unzip the attached ZIP file. Open a command line in
the /build subfolder and call

cmake -G"Visual Studio 10" ..

Then do a

cmake --build .

Watch how test1.cpp is compiled properly. Then open CMakeLists.txt and uncomment
the line with test2.cpp. Do an incremental build by calling

cmake --build .

The change of CMakeLists.txt is detected but test2.cpp is NOT COMPILED! Do a
second incremental build

cmake --build .

Now test2.cpp is compiled.

Delete the bugreport folder and extract it again from the ZIP file to return to
the initial state. Open the CMakeLists.txt and rename the 'Notworking' target
name in add_library to 'working'. Repeat all steps above and you will see that
test2.cpp is compiled in the first incremental build already, as one would
expect.

I tested a lot of combinations and it seems that the capital letter in front
seems to be the source of the problem.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-09-21 10:54 Johannes Asal  New Issue
2015-09-21 10:54 Johannes Asal  File Added: bugreport.zip
==

-- 

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 0015756]: FindLua.cmake doesn't work when both Lua5.2 and Lua5.3 are installed.

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=15756 
== 
Reported By:Alan Witkowski
Assigned To:
== 
Project:CMake
Issue ID:   15756
Category:   Modules
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-09-21 15:15 MDT
Last Modified:  2015-09-21 15:15 MDT
== 
Summary:FindLua.cmake doesn't work when both Lua5.2 and
Lua5.3 are installed.
Description: 
If you call find_package(Lua 5.2 REQUIRED) or find_package(Lua REQUIRED) this
happens:

Found Lua: /usr/lib64/liblua5.2.so;/usr/lib64/libm.so (found suitable version
"5.3.1", minimum required is "5.2")

Basically the 5.2 library is found but it still uses the 5.3 include path, hence
the wrong "suitable version":

CMakeCache.txt
LUA_INCLUDE_DIR:PATH=/usr/include
LUA_LIBRARY:FILEPATH=/usr/lib64/liblua5.2.so

Calling find_package(Lua 5.3 REQUIRED) works fine though.

Additional Information: 
lua5.3 is installed to /usr/include
lua5.2 is installed to /usr/include/lua5.2
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-09-21 15:15 Alan Witkowski 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] Add command line options for deprecation message control

[Michael Scott]

The -Wdev/-Wno-dev options have always been for all messages
output by any part of CMake.  This needs to be preserved/corrected.
Okay, I've fixed the change to cmake::PrintMessagePreamble, so that 
it'll stop warning or error dev or deprecated messages getting printed 
out when the relevant CMake variables have been set. I just need to add 
some more test cases to cover this and I'll submit a patch.



Likely yes.  This may require sweeping changes to address.  We're
too close to the freeze for 3.4 to do this now.  Perhaps we should
simply remove -Werr-dev for now.


Yes the -Werr-dev, -Wno-err-dev, -Werr-deprectated and 
-Wno-err-deprecated may be trickier than expected to get behaving as 
intended. I'll try and get a better idea of the users of IssueMessage 
and see if some ideas come to mind. Removing them would be fair enough 
at this point, better to not include them than to include broken 
functionality I'm sure. Do new features, such as -Werr-dev, have to be 
sent by October 1st is it?


Cheers,
Michael

--

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] CPack/NSIS is broken after extended length paths fix

[Dmitry Kochkin]

 Hi Clint,

>>Actually it's even worse because in current master HEAD I can see that 
>>INST_DIR is empty in generated project:
>>  !define INST_DIR ""
>>(not sure if that's caused by your change)
>Interesting... Do you know why this happens?  How is this problem related to 
>extended paths (with the \\?\ prefix)?  Do you have an example to demonstrate 
>this problem? That was my mistake, please ignore.
>>I've figured out that NSIS was not going to fix this (see  
>>http://sourceforge.net/p/nsis/feature-requests/241/ )
>
>Maybe they'll accept a patch to fix it there?  Was there any effort to fix it 
>there?
In the URL I've put they claim you should just use "\\?\" in your NSIS project.
I guess it's also possible to fix NSIS, but we cannot rely that user have 
latest NSIS.

>
>>
>>I've made a small patch to NSIS generator and template to put infamous \\?\ 
>>there.
>>
>>I can send directly to you as I guess you know more about these parts of code.
>
>You can send your patch to this mailing list for review.
Patch attached. It's a bit hacky, more fixing symptoms I guess. The purpose is 
only to demonstrate the idea.
Let me know if it can be done in better way.

Regards,
Dmitry


From a14fc375593f2d150dba8f93d34f04b954c9365e Mon Sep 17 00:00:00 2001
From: Dmitry Kochkin 
Date: Mon, 21 Sep 2015 11:23:19 +0200
Subject: [PATCH] Fixing NSIS packer for very long filenames on Windows

---
 Modules/NSIS.template.in  |  4 ++--
 Source/CPack/cmCPackNSISGenerator.cxx | 10 --
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/Modules/NSIS.template.in b/Modules/NSIS.template.in
index 76310af..0fe19fe 100644
--- a/Modules/NSIS.template.in
+++ b/Modules/NSIS.template.in
@@ -5,7 +5,7 @@
 
   !define VERSION "@CPACK_PACKAGE_VERSION@"
   !define PATCH  "@CPACK_PACKAGE_VERSION_PATCH@"
-  !define INST_DIR "@CPACK_TEMPORARY_DIRECTORY@"
+  !define INST_DIR "@CPACK_TEMPORARY_DIRECTORY_SAFE@"
 
 ;
 ;Variables
@@ -639,7 +639,7 @@ FunctionEnd
 Section "-Core installation"
   ;Use the entire tree produced by the INSTALL target.  Keep the
   ;list of directories here in sync with the RMDir commands below.
-  SetOutPath "$INSTDIR"
+  SetOutPath "\\?\$INSTDIR"
   @CPACK_NSIS_EXTRA_PREINSTALL_COMMANDS@
   @CPACK_NSIS_FULL_INSTALL@
 
diff --git a/Source/CPack/cmCPackNSISGenerator.cxx b/Source/CPack/cmCPackNSISGenerator.cxx
index 6cdda28..6676d3a 100644
--- a/Source/CPack/cmCPackNSISGenerator.cxx
+++ b/Source/CPack/cmCPackNSISGenerator.cxx
@@ -46,6 +46,12 @@ cmCPackNSISGenerator::~cmCPackNSISGenerator()
 //--
 int cmCPackNSISGenerator::PackageFiles()
 {
+  std::string win_safe_tmp( this->GetOption( "CPACK_TEMPORARY_DIRECTORY" ) );
+#ifdef _WIN32
+  cmSystemTools::ReplaceString(win_safe_tmp, "/", "\\");
+  win_safe_tmp = "?\\" + win_safe_tmp;
+#endif
+  this->SetOptionIfNotSet( "CPACK_TEMPORARY_DIRECTORY_SAFE", win_safe_tmp.c_str( ) );
   // TODO: Fix nsis to force out file name
 
   std::string nsisInFileName = this->FindTemplate("NSIS.template.in");
@@ -83,7 +89,7 @@ int cmCPackNSISGenerator::PackageFiles()
   fileN = fileN.substr(fileN.find('/')+1, std::string::npos);
   }
 cmSystemTools::ReplaceString(fileN, "/", "\\");
-str << "  Delete \"$INSTDIR\\" << fileN << "\"" << std::endl;
+str << "  Delete \"?\\$INSTDIR\\" << fileN << "\"" << std::endl;
 }
   cmCPackLogger(cmCPackLog::LOG_DEBUG, "Uninstall Files: "
 << str.str() << std::endl);
@@ -117,7 +123,7 @@ int cmCPackNSISGenerator::PackageFiles()
 }
   }
 cmSystemTools::ReplaceString(fileN, "/", "\\");
-dstr << "  RMDir \"$INSTDIR\\" << fileN << "\"" << std::endl;
+dstr << "  RMDir \"?\\$INSTDIR\\" << fileN << "\"" << std::endl;
 if (!componentName.empty())
   {
   this->Components[componentName].Directories.push_back(fileN);
-- 
2.5.1.windows.1

-- 

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