Re: [cmake-developers] Code style auto-formatting

[Kislinskiy, Stefan]

Do you know ClangFormat[1]? Pretty popular choice these days. You just put a 
format description file into your repository (which can be based on popular 
styles + your exceptions to keep the file rather small). It can be integrated 
into many editors including the Visual Studio IDE. You probably want to add a 
hook to your git repository to automatically format your code when committing. 
See the link for details.

Best regards,
Stefan

[1] http://clang.llvm.org/docs/ClangFormat.html


Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von 
Stuermer, Michael  SP/HZA-ZSEP [michael.stuer...@schaeffler.com]
Gesendet: Dienstag, 17. November 2015 09:14
An: CMake Developers
Betreff: Re: [cmake-developers] Code style auto-formatting

I asked something similar half a year ago:

https://cmake.org/pipermail/cmake-developers/2015-June/025498.html

In short, there is no fully automated style checking. If someone would come up 
with a tool & configuration I would love to use this. So far I tested astyle 
and the C++ edition of ReSharper (unfortunately quite expensive).

The more complicated thing would be, that you have to run the formatter over 
all existing code and thus you would introduce a huge amount of meaningless 
changes. I believe (and partially understand) many developers here on the list 
wouldn't really like large cosmetic changes like this.

best regards,
Michael

> -Original Message-
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
> On Behalf Of Robert Dailey
> Sent: Tuesday, November 17, 2015 3:01 AM
> To: CMake Developers
> Subject: [cmake-developers] Code style auto-formatting
>
> IMHO, the code style in the CMake code base is incredibly inconsistent, but
> even the consistent style that is there is a giant pain to follow by hand.
>
> I'm constantly fighting my tooling's auto formatting. I prefer to keep my code
> additions similar to surrounding code. Do you use some tool such as clang-
> format to auto format code? This will make it easier to make my style more
> consistent after my work is completed.
>
> Thanks in advance.
> --
>
> 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
--

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

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 factored out the code from cmOutputConverter::ConvertToOutputFormat() into 
another helper method called ConvertDirectorySeparatorsForShell(), changed the 
SHELL_PATH genex to accept only absolute paths, and changed its documentation 
accordingly. I also added a BadSHELL_PATH test to the 
RunCMake/GeneratorExpression tests, that use the SHELL_PATH genex with an empty 
parameter as well as a relative path. I also fixed the TEST/CTEST typo you 
discovered yesterday.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Mittwoch, 23. September 2015 16:57
To: Kislinskiy, Stefan
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] generator expression for path slash conversion

On 09/23/2015 10:45 AM, Kislinskiy, Stefan wrote:
> I see. I would suggest that I add another output flag to 
> cmOutputConverter like SHELL_NO_ESCAPE then. If this flag is passed to 
> ConvertToOutputFormat() instead of SHELL, the call of
> EscapeForShell() will be circumvented. This way there wouldn't be code 
> duplication and we would still cover the MSYS case (drive letter 
> conversion).

The conversion code in question is about 10 lines and could be factored out 
into another helper method.  Then the genex impl could just use the helper 
directly.

> Isn't it possible to specify parameters for generator expressions?

Yes.

> How about something like $?

Neat idea.  However, for now I'd rather not try to predict the use cases for 
which such parameters will be needed.  Instead we should just make sure the 
interface leaves room for future extension.  Since "," is allowed in paths we 
cannot simply disallow it or blindly use it as a separator.  Therefore we 
should have the actual path always be the last parameter.

For now I think you can just require (with an error) that the value given to 
SHELL_PATH as input must be an absolute path (cmSystemTools::FileIsFullPath).  
Then in the future we could recognize things like $<SHELL_PATH:ESCAPE,c:/path> 
without ambiguity.  Please include test cases for errors on relative paths (see 
Tests/RunCMake/GeneratorExpression).

Thanks,
-Brad



shell_path_genex_v4.patch
Description: shell_path_genex_v4.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

[Kislinskiy, Stefan]

Great, thank you, Brad & David.

Regarding the ExternalProjectShellPathGenex test: I wrongly assumed that the 
WIN32 variable wouldn't be set when using MSYS and the like. Would it make 
sense to keep the test when changing the WIN32 check to MSVC? Good to know that 
pushd is working for quoted paths. As I didn't use paths with spaces, the 
argument wasn't quoted and the test worked like expected for me (succeeded with 
the SHELL_PATH genex and failed when I removed the SHELL_PATH genex). We could 
ensure that there isn't any space character in the argument by using a 
top-level path like C:/. Not hard coded but derived from a variable like 
CMAKE_SOURCE_DIR. Or, of course, there is a standard Windows command out there 
that cannot handle slashed even if they are quoted (any idea?). I chose pushd, 
as that was the command that started it all (used indirectly by the Boost build 
scripts).

Regarding the nice bracket tweak: Maybe the minimum required version in 
Tests/GeneratorExpression/CMakeLists.txt should be updated to 3.0.0 then?

Stefan

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Donnerstag, 24. September 2015 16:22
To: Kislinskiy, Stefan
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] generator expression for path slash conversion

On 09/24/2015 09:05 AM, Kislinskiy, Stefan wrote:
> I factored out the code from 
> cmOutputConverter::ConvertToOutputFormat()
> into another helper method called 
> ConvertDirectorySeparatorsForShell(),
> changed the SHELL_PATH genex to accept only absolute paths, and 
> changed its documentation accordingly. I also added a BadSHELL_PATH 
> test to the RunCMake/GeneratorExpression tests, that use the 
> SHELL_PATH genex with an empty parameter as well as a relative path. I 
> also fixed the TEST/CTEST typo you discovered yesterday.

Thanks.  I started with a change to simplify the test infrastructure slightly:

 Tests: Simplify GeneratorExpression check implementation
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7de868c4

Then I applied your changes with minor tweaks and merged to 'next'
for testing:

 Genex: Add a SHELL_PATH expression
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8adf6ab5

I left out the ExternalProjectShellPathGenex test because it fails on the 
Ninja, MSYS Makefiles, and MinGW Makefiles generators on Windows.  The 'pushd' 
and 'popd' commands do not work there due to the way the build tool runs the 
command in a shell.  It passed for me only in a VS IDE generator.  See also 
David Cole's sibling response about this test.

-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, added a genex test that checks it the given path is 
converted as expected on different platforms, and added another ExternalProject 
test for Windows that invokes pushd, which is is command sensitive to the path 
style. I wasn't sure about the VERSION I am supposed to write into the 
cmake_minimum_required() line in 
Tests/ExternalProjectShellPathGenex/CMakeLists.txt, so I chose 3.3.20150923. 
Maybe you need to adjust the version there? I tried to be as consistent as 
possible regarding the tests and their already existing fellow tests.

-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_v3.patch
Description: shell_path_genex_v3.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

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

[Kislinskiy, Stefan]

Sorry for the late answer, I was on vacation. 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? If it is okay 
I would write some documentation as well of course.

- Stefan


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Montag, 31. August 2015 21:33
To: Kislinskiy, Stefan
Cc: CHEVRIER, Marc; cmake-developers@cmake.org; James Johnston
Subject: Re: [cmake-developers] generator expression for path slash conversion 
(was: ExternalProject: Use native paths as substitute for directory tokens)

On 08/31/2015 09:35 AM, Kislinskiy, Stefan wrote:
> As there is already a patch for such a genex in bug 15509 and the 
> discussion in 5939 (both linked below in Brad's reply) started 7 years 
> ago... It would be a great pity to let this issue seep away again. 
> What can I do to help fixing this finally?

Someone will need to think through and propose a specific genex that does the 
path conversion that makes sense in this context.  I think something like 
$ may be appropriate.

For referencing command line tools (as argv[0]) the C++ side uses code like 
this now:

 this->ConvertToOutputFormat(ccg.GetCommand(i), SHELL)

This genex should map to the same conversion internally.

-Brad



shell_path_genex.patch
Description: shell_path_genex.patch
cmake_minimum_required(VERSION 3.3.20150917 FATAL_ERROR)

project(Test VERSION 0.0.0.0 LANGUAGES NONE)

include(ExternalProject)

ExternalProject_Add(CMakeStyle
  SOURCE_DIR ${CMAKE_BINARY_DIR}
  CONFIGURE_COMMAND echo 
  BUILD_COMMAND echo 
  INSTALL_COMMAND echo 
)

ExternalProject_Add_Step(CMakeStyle custom
  COMMAND echo 
  DEPENDERS configure
)

ExternalProject_Add(ShellStyle
  SOURCE_DIR ${CMAKE_BINARY_DIR}
  CONFIGURE_COMMAND echo $<SHELL_PATH:>
  BUILD_COMMAND echo $<SHELL_PATH:>
  INSTALL_COMMAND echo $<SHELL_PATH:>
)

ExternalProject_Add_Step(ShellStyle custom
  COMMAND echo $<SHELL_PATH:>
  DEPENDERS configure
)
-- 

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] ExternalProject: Use native paths as substitute for directory tokens

[Kislinskiy, Stefan]

As there is already a patch for such a genex in bug 15509 and the discussion in 
5939 (both linked below in Brad's reply) started 7 years ago... It would be a 
great pity to let this issue seep away again. What can I do to help fixing this 
finally?

Stefan 

-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
CHEVRIER, Marc
Sent: Freitag, 28. August 2015 10:07
To: Brad King; cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute 
for directory tokens


Offering generator-expressions is a very good idea because it offers a global 
solution to this problem.

Now regarding the name of the generator, may be TO_NATIVE_PATH is not 
judicious, (even if problems explained in 
http://www.cmake.org/Bug/view.php?id=5939 are, in my point of view, linked to 
platforms not well handled rather than wrong semantic of TO_NATIVE_PATH) but 
PATH_FOR_SHELL is, as well, ambiguous at least for two reasons:
* commands defined in add_custom_command, for example, are directly executed 
without any shell evolved
* A system can have multiple shells supporting different paths syntax. For 
example, on windows, my shell is tcsh which handle paths with ‘/‘ rather than 
‘\'

May be, TO_SYSTEM_PATH or TO_HOST_SYSTEM_PATH make more sense…

Marc




On 27/08/15 17:18, "cmake-developers on behalf of Brad King" 
 wrote:

>On 08/27/2015 10:06 AM, James Johnston wrote:
>> I would vote naming it TO_NATIVE_PATH instead of PATH_FOR_SHELL, for 
>> consistency with the existing parameter in the file command.
>
>The file(TO_NATIVE_PATH) command is hopelessly ill-defined:
>
> http://www.cmake.org/Bug/view.php?id=5939
>
>See also existing discussion about a genex for such conversions:
>
> http://www.cmake.org/Bug/view.php?id=15509
>
>-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
-- 

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

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] ExternalProject: Use native paths as substitute for directory tokens

[Kislinskiy, Stefan]

This is pretty nice from the perspective of an engineer. But I wonder if it 
wouldn't be kind of over-engineered in the sense that it would be a rather 
hidden feature for the purpose? -- I probably wouldn't think of searching for a 
generator expression in the documentation when I have trouble with the 
replacement of directory tokens. Then again, there could be a hint in the 
ExternalProject documentation which would be fine I guess. One way or another, 
I would be happy if we could determine what the patch should provide exactly so 
that we come to an end. :-) Thank you for all the feedback so far.  


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Donnerstag, 27. August 2015 15:10
To: Kislinskiy, Stefan; CHEVRIER, Marc; David Cole
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute 
for directory tokens

On 08/26/2015 03:35 AM, Kislinskiy, Stefan wrote:
 Would you prefer to have a switch for each *_DIR variable for all 
 target steps, or a common switch but for each target step, like the 
 new USE_TERMINAL switches in the master?
[snip]
 Von: CHEVRIER, Marc [marc.chevr...@sap.com] Offering the possibility 
 to manage native paths in an easy way is a very good enhancement

Another approach is to introduce a generator expression to transform the path 
slash style.  Then it could be used both for ExternalProject and in other 
custom commands.  E.g.

 $PATH_FOR_SHELL:SOURCE_DIR/bootstrap${shell_ext}

In this case SOURCE_DIR would be replaced with forward slashes by 
ExternalProject but then at generate time CMake would evaluate the genex to 
convert slashes as needed.

-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] ExternalProject: Use native paths as substitute for directory tokens

[Kislinskiy, Stefan]

Yes, TO_CMAKE_PATH is used quite often. Just imagine parsing paths as input. Or 
when you create CMake scripts during the build you might want to call 
file(TO_CMAKE_PATH) in there. It makes sense on both ends, as input and output. 
:) I also vote for consistent naming, if the generator expressions are chosen 
as the final solution.

-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
James Johnston
Sent: Donnerstag, 27. August 2015 16:06
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute 
for directory tokens

 -Original Message-
 From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
 On Behalf Of Kislinskiy, Stefan
 Sent: Thursday, August 27, 2015 13:44
 To: Brad King; CHEVRIER, Marc; David Cole
 Cc: cmake-developers@cmake.org
 Subject: Re: [cmake-developers] ExternalProject: Use native paths as 
 substitute for directory tokens
 
 This is pretty nice from the perspective of an engineer. But I wonder 
 if
it
 wouldn't be kind of over-engineered in the sense that it would be a 
 rather hidden feature for the purpose? -- I probably wouldn't think of 
 searching
for
 a generator expression in the documentation when I have trouble with 
 the replacement of directory tokens. Then again, there could be a hint 
 in the ExternalProject documentation which would be fine I guess. One 
 way or another, I would be happy if we could determine what the patch 
 should provide exactly so that we come to an end. :-) Thank you for 
 all the
feedback
 so far.

I think Brad raises an excellent point here though I hadn't thought of...
implementing the underlying functionality as a generator expression allows the 
problem to be solved outside of the scope of ExternalProject when it arises...  
For example if I add_custom_command as a custom build step and need to pass a 
native path argument to it - a path known only at generate time.  I guess it is 
not possible right now?

 Another approach is to introduce a generator expression to transform 
 the path slash style.  Then it could be used both for ExternalProject 
 and in
other
 custom commands.  E.g.
 
  $PATH_FOR_SHELL:SOURCE_DIR/bootstrap${shell_ext}
 
 In this case SOURCE_DIR would be replaced with forward slashes by 
 ExternalProject but then at generate time CMake would evaluate the 
 genex to convert slashes as needed.

I would vote naming it TO_NATIVE_PATH instead of PATH_FOR_SHELL, for 
consistency with the existing parameter in the file command.  There could then 
also be a corresponding TO_CMAKE_PATH gen-exp, although I wonder if it would be 
used much.  (Then again, do people even use file(TO_CMAKE_PATH) very much?) 

James


-- 

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

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] ExternalProject: Use native paths as substitute for directory tokens

[Kislinskiy, Stefan]

Would you prefer to have a switch for each *_DIR variable for all target steps, 
or a common switch but for each target step, like the new USE_TERMINAL switches 
in the master?

Von: CHEVRIER, Marc [marc.chevr...@sap.com]
Gesendet: Mittwoch, 26. August 2015 08:49
An: David Cole; Kislinskiy, Stefan
Cc: cmake-developers@cmake.org
Betreff: Re: [cmake-developers] ExternalProject: Use native paths as substitute 
for directory tokens

I agree with David.

Offering the possibility to manage native paths in an easy way is a very good 
enhancement (Today, I rely on some specific actions when I am on Win32 to 
manage native path for ONE specific step of ExternalProject) BUT, offering only 
the alternative to have NONE or ALL paths in native form is, by far, too 
restrictive.
So I am for the solution providing new patterns as alternative to current ones 
to manage native paths, i.e. Adding *_NATIVE_DIR for all already available 
*_DIR patterns.

Marc



On 25/08/15 17:31, cmake-developers on behalf of David Cole via 
cmake-developers cmake-developers-boun...@cmake.org on behalf of 
cmake-developers@cmake.org wrote:

I'm going to let other CMake developers chime in on this one.

It's better than the first patch, because it's opt-in, and you have to
add something to get different than previous behavior, but I'm still
of the opinion that this is very command specific, and you won't
always want all _DIR references as native. In my opinion, it's better
left to the person constructing the ExternalProject_Add call. But I am
curious to hear other CMake devs give their opinions.


David C.



On Tue, Aug 25, 2015 at 3:18 AM, Kislinskiy, Stefan
s.kislins...@dkfz-heidelberg.de wrote:
 Dear CMake developers,

 any thoughts on the fix? :)

 Best regards,
 Stefan Kislinskiy
 
 Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von 
 Kislinskiy, Stefan [s.kislins...@dkfz-heidelberg.de]
 Gesendet: Freitag, 21. August 2015 23:56
 An: David Cole; James Johnston
 Cc: cmake-developers@cmake.org
 Betreff: Re: [cmake-developers] ExternalProject: Use native paths as 
 substitute for directory tokens

 What do you think about the new patch I attached to this mail? It adds an 
 option NATIVE_DIR_TOKENS to ExternalProjects_Add. I also attached a CMake 
 script file which tests/shows this feature.

 Stefan Kislinskiy
 
 Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von 
 David Cole via cmake-developers [cmake-developers@cmake.org]
 Gesendet: Donnerstag, 20. August 2015 23:20
 An: James Johnston
 Cc: cmake-developers@cmake.org
 Betreff: Re: [cmake-developers] ExternalProject: Use native paths as 
 substitute for directory tokens

 It's exactly what I am concerned about:

 You're asking to change the behavior of something for EVERYONE to
 solve a problem which you have encountered. If you change it the way
 you have proposed, you will cause problems for others. It has worked
 the way it is now since ExternalProject_Add was introduced in CMake
 2.8. Changing it unconditionally the way you propose is simply not
 feasible for backwards compatibility.

 I think commands that take native paths ought NOT to use the *_DIR
 replacement values, and instead, ought to pass in variables that
 contain the native paths in the first place.


 David C.



 On Thu, Aug 20, 2015 at 2:58 PM, James Johnston
 johnstonj.pub...@codenest.com wrote:
 Hi,

 Funny you are mailing the list about this, since I just ran into this same 
 issue today building something totally different from Boost...  In this 
 case it's a build tool that thinks the /U in C:/Users is a new command 
 line argument, that isn't recognized - and then the subsequent s also 
 ends up unrecognized... and it all fails...  And it has nothing to do with 
 the working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible 
 workaround for me.

 I think the issue with globally making this change to the existing tokens 
 is that there could be some external tool/program that is EXPECTING to get 
 CMake paths, not native paths.  Who knows?  I am guessing that is what 
 David Cole was concerned about.

 Maybe the right answer is to introduce some NEW tokens while leaving the 
 behavior of the old ones unchanged.  E.g. BINARY_DIR_NATIVE etc.  It 
 would be good if the patch updates the documentation of ExternalProject and 
 clearly states the path format of BINARY_DIR vs BINARY_DIR_NATIVE.  
 Then the user can pick whichever one suits them best, depending on the tool 
 being invoked.

 Furthermore, sometimes BINARY_DIR_NATIVE still needs to be replaced with 
 a CMake path, not native path.  For example, if the token is being found in 
 a property like WORKING_DIRECTORY that eventually gets passed to 
 add_custom_command(WORKING_DIRECTORY) then I'm guessing still has to be a 
 CMake path.  I am guessing this is what David Cole was also

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

[Kislinskiy, Stefan]

I see. Added native-style path replacements for SOURCE_NATIVE_DIR and so on. 
Also extended the documentation accordingly.

Von: CHEVRIER, Marc [marc.chevr...@sap.com]
Gesendet: Mittwoch, 26. August 2015 10:26
An: Kislinskiy, Stefan; David Cole
Cc: cmake-developers@cmake.org
Betreff: Re: AW: [cmake-developers] ExternalProject: Use native paths as 
substitute for directory tokens

I didn’t even think about switches. I don’t think they are required.
Adding the capability to handle paths in native format seems enough.

Example: I want to use a specific tool for the build step which supports only 
native paths
ExternalProjet_add (
….
SOURCE_DIR c:/sources/my_project
….
BUILD_COMMAND ${MY_CUSTOM_COMMAND} -IN SOURCE_NATIVE_DIR -OUT 
BINARY_NATIVE_DIR
…
)

With this approach, the previous behaviour is ensured and it is easy, for 
specify cases, to use native paths.





On 26/08/15 09:35, Kislinskiy, Stefan s.kislins...@dkfz-heidelberg.de wrote:

Would you prefer to have a switch for each *_DIR variable for all target 
steps, or a common switch but for each target step, like the new USE_TERMINAL 
switches in the master?

Von: CHEVRIER, Marc [marc.chevr...@sap.com]
Gesendet: Mittwoch, 26. August 2015 08:49
An: David Cole; Kislinskiy, Stefan
Cc: cmake-developers@cmake.org
Betreff: Re: [cmake-developers] ExternalProject: Use native paths as 
substitute for directory tokens

I agree with David.

Offering the possibility to manage native paths in an easy way is a very good 
enhancement (Today, I rely on some specific actions when I am on Win32 to 
manage native path for ONE specific step of ExternalProject) BUT, offering 
only the alternative to have NONE or ALL paths in native form is, by far, too 
restrictive.
So I am for the solution providing new patterns as alternative to current ones 
to manage native paths, i.e. Adding *_NATIVE_DIR for all already available 
*_DIR patterns.

Marc



On 25/08/15 17:31, cmake-developers on behalf of David Cole via 
cmake-developers cmake-developers-boun...@cmake.org on behalf of 
cmake-developers@cmake.org wrote:

I'm going to let other CMake developers chime in on this one.

It's better than the first patch, because it's opt-in, and you have to
add something to get different than previous behavior, but I'm still
of the opinion that this is very command specific, and you won't
always want all _DIR references as native. In my opinion, it's better
left to the person constructing the ExternalProject_Add call. But I am
curious to hear other CMake devs give their opinions.


David C.



On Tue, Aug 25, 2015 at 3:18 AM, Kislinskiy, Stefan
s.kislins...@dkfz-heidelberg.de wrote:
 Dear CMake developers,

 any thoughts on the fix? :)

 Best regards,
 Stefan Kislinskiy
 
 Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von 
 Kislinskiy, Stefan [s.kislins...@dkfz-heidelberg.de]
 Gesendet: Freitag, 21. August 2015 23:56
 An: David Cole; James Johnston
 Cc: cmake-developers@cmake.org
 Betreff: Re: [cmake-developers] ExternalProject: Use native paths as 
 substitute for directory tokens

 What do you think about the new patch I attached to this mail? It adds an 
 option NATIVE_DIR_TOKENS to ExternalProjects_Add. I also attached a CMake 
 script file which tests/shows this feature.

 Stefan Kislinskiy
 
 Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von 
 David Cole via cmake-developers [cmake-developers@cmake.org]
 Gesendet: Donnerstag, 20. August 2015 23:20
 An: James Johnston
 Cc: cmake-developers@cmake.org
 Betreff: Re: [cmake-developers] ExternalProject: Use native paths as 
 substitute for directory tokens

 It's exactly what I am concerned about:

 You're asking to change the behavior of something for EVERYONE to
 solve a problem which you have encountered. If you change it the way
 you have proposed, you will cause problems for others. It has worked
 the way it is now since ExternalProject_Add was introduced in CMake
 2.8. Changing it unconditionally the way you propose is simply not
 feasible for backwards compatibility.

 I think commands that take native paths ought NOT to use the *_DIR
 replacement values, and instead, ought to pass in variables that
 contain the native paths in the first place.


 David C.



 On Thu, Aug 20, 2015 at 2:58 PM, James Johnston
 johnstonj.pub...@codenest.com wrote:
 Hi,

 Funny you are mailing the list about this, since I just ran into this same 
 issue today building something totally different from Boost...  In this 
 case it's a build tool that thinks the /U in C:/Users is a new command 
 line argument, that isn't recognized - and then the subsequent s also 
 ends up unrecognized... and it all fails...  And it has nothing to do with 
 the working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible 
 workaround for me

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

[Kislinskiy, Stefan]

Dear CMake developers,

any thoughts on the fix? :)

Best regards,
Stefan Kislinskiy

Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von 
Kislinskiy, Stefan [s.kislins...@dkfz-heidelberg.de]
Gesendet: Freitag, 21. August 2015 23:56
An: David Cole; James Johnston
Cc: cmake-developers@cmake.org
Betreff: Re: [cmake-developers] ExternalProject: Use native paths as substitute 
for directory tokens

What do you think about the new patch I attached to this mail? It adds an 
option NATIVE_DIR_TOKENS to ExternalProjects_Add. I also attached a CMake 
script file which tests/shows this feature.

Stefan Kislinskiy

Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von David 
Cole via cmake-developers [cmake-developers@cmake.org]
Gesendet: Donnerstag, 20. August 2015 23:20
An: James Johnston
Cc: cmake-developers@cmake.org
Betreff: Re: [cmake-developers] ExternalProject: Use native paths as substitute 
for directory tokens

It's exactly what I am concerned about:

You're asking to change the behavior of something for EVERYONE to
solve a problem which you have encountered. If you change it the way
you have proposed, you will cause problems for others. It has worked
the way it is now since ExternalProject_Add was introduced in CMake
2.8. Changing it unconditionally the way you propose is simply not
feasible for backwards compatibility.

I think commands that take native paths ought NOT to use the *_DIR
replacement values, and instead, ought to pass in variables that
contain the native paths in the first place.


David C.



On Thu, Aug 20, 2015 at 2:58 PM, James Johnston
johnstonj.pub...@codenest.com wrote:
 Hi,

 Funny you are mailing the list about this, since I just ran into this same 
 issue today building something totally different from Boost...  In this case 
 it's a build tool that thinks the /U in C:/Users is a new command line 
 argument, that isn't recognized - and then the subsequent s also ends up 
 unrecognized... and it all fails...  And it has nothing to do with the 
 working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible 
 workaround for me.

 I think the issue with globally making this change to the existing tokens is 
 that there could be some external tool/program that is EXPECTING to get CMake 
 paths, not native paths.  Who knows?  I am guessing that is what David Cole 
 was concerned about.

 Maybe the right answer is to introduce some NEW tokens while leaving the 
 behavior of the old ones unchanged.  E.g. BINARY_DIR_NATIVE etc.  It would 
 be good if the patch updates the documentation of ExternalProject and clearly 
 states the path format of BINARY_DIR vs BINARY_DIR_NATIVE.  Then the user 
 can pick whichever one suits them best, depending on the tool being invoked.

 Furthermore, sometimes BINARY_DIR_NATIVE still needs to be replaced with a 
 CMake path, not native path.  For example, if the token is being found in a 
 property like WORKING_DIRECTORY that eventually gets passed to 
 add_custom_command(WORKING_DIRECTORY) then I'm guessing still has to be a 
 CMake path.  I am guessing this is what David Cole was also concerned about.

 I still think your original method of building Boost is a bit unusual and 
 would be better served by _Add_Step with a custom working directory - because 
 that's the publicly documented/standard way of changing the working 
 directory, but that is up to you.  :)

 Best regards,

 James Johnston


  On Thu, 20 Aug 2015 14:37:08 +  Stefan Kislinskiy 
 s.kislins...@dkfz-heidelberg.de wrote 

   Hi,
  
   thank you for our suggestions. I am aware that I can solve my example 
 differently and that it might look not directly connected the proposal, but 
 well, it is an example just to show a single case and why it matters. :) I 
 did not want to discuss the example itself. Working around here would just 
 resolve a symptom.
  
   My point is the overall problem that would persist: A big part of 
 ExternalProject is to issue commands for predefined and custom steps. Those 
 commands are supposed to be executed by the shell/command line. According to 
 the documentation and the source code of ExternalProject, directory tokens 
 are mainly supposed to be replaced in commands. It is my understanding, that 
 it is a bug, if CMake isn't able to assemble these commands correctly. This 
 would include usage of the correct path style of the OS for shell/command 
 line commands. As directory tokens are replaced internally right before a 
 shell/command line command is assembled, I can't see why this would be kind 
 of API-breaking. You cannot interfere in your CMake code with these 
 internal replacements.
  
   Therefore I would still prefer my solution as it is pretty simple without 
 adding even more features to ExternalProject and in my opinion without 
 breaking code in the wild. It is a true bug fix instead of a feature

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

[Kislinskiy, Stefan]

 that this is how things are 
 currently done in ExternalProject and always were as far as I know, for 
 example (from ExternalProject.cmake):
  
 add_custom_command(
   OUTPUT ${stamp_file}
   BYPRODUCTS ${byproducts}
   COMMENT ${comment}
   COMMAND ${command}
   COMMAND ${touch}
   DEPENDS ${depends}
   WORKING_DIRECTORY ${work_dir}
   VERBATIM
   )
  
   Best regards,
   Stefan
  
  
   -Original Message-
   From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On 
 Behalf Of James Johnston
   Sent: Donnerstag, 20. August 2015 15:37
   To: cmake-developers@cmake.org
   Subject: Re: [cmake-developers] ExternalProject: Use native paths as 
 substitute for directory tokens
  
-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
On Behalf Of Kislinskiy, Stefan
Sent: Thursday, August 20, 2015 09:02
To: David Cole
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as
substitute for directory tokens
   
Hi David,
   
Example excerpt (it is not possible to change the working directory
for
   the
CONFIGURE_COMMAND as it is fixed to the BUILD_DIR, which might not be
sufficient):
  
   This doesn't really directly have to do with your proposal, but what if an 
 option was added to change the working dir of the CONFIGURE_COMMAND?  E.g.
   WORKING_DIRECTORY_CONFIGURE.  And suppose you'd have it recognize the 
 various tags like SOURCE_DIR, etc.  This might be useful to add to other 
 steps as well, and would be more portable than your solution which is using 
 cmd.exe-specific commands.  You'd want to audit for any resulting breakage 
 (e.g. does ExternalProject make assumptions that the working directory of 
 CONFIGURE is always the binary dir? - e.g. a relative path being used 
 somewhere.  And probably only allow specification of 
 WORKING_DIRECTORY_CONFIGURE if a CONFIGURE_COMMAND was also specified, as the 
 built-in commands certainly assume the default working dir.)
  
   In your situation though, I'm not sure it's strictly needed.  From your 
 sample, it looks like you're building boost.  In your case what if you:
  
* Use ExternalProject_Add_Step to bootstrap.  You can specify a 
 WORKING_DIRECTORY here.  Note one problem: you can't do out of source build 
 of b2, which breaks user expectations.
* Then use ExternalProject_Add_Step to build Boost.
  
   Yes, using _Add_Step is somewhat of a workaround, but in this case, I've 
 found it wasn't much of a burden at all.  In fact the only case I can think 
 of where it WOULD be a burden would be if the configure step is CMake.  But 
 then you wouldn't need to change the working directory; changing it would 
 break CMake.  In practice nobody will want to change WORKING_DIRECTORY unless 
 it's a custom command and then it's easy to use _Add_Step anyway.
   That said, it might still be considered a little undesired and so maybe my 
 proposal above would be a better way to handle it.
  
   Corrections from maintainers and others on the above commentary are 
 welcome...
  
   
set(bootstrap_cmd SOURCE_DIR/bootstrap${shell_ext}
${bootstrap_toolset})
   
if(WIN32)
  set(bootstrap_cmd pushd SOURCE_DIR COMMAND ${bootstrap_cmd}
COMMAND popd)
endif()
   
ExternalProject_Add(Boost
  ...
  CONFIGURE_COMMAND ${bootstrap_cmd}
  ...
)
  
   From add_custom_command:  If more than one COMMAND is specified they will 
 be executed in order, but not necessarily composed into a stateful shell or 
 batch script.
  
   So I am not sure your approach will work for you even if you fix the issue 
 with path slashes.
  
   James
  

 --

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

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

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

[Kislinskiy, Stefan]

 and 
 would be better served by _Add_Step with a custom working directory - because 
 that's the publicly documented/standard way of changing the working 
 directory, but that is up to you.  :)

 Best regards,

 James Johnston


  On Thu, 20 Aug 2015 14:37:08 +  Stefan Kislinskiy 
 s.kislins...@dkfz-heidelberg.de wrote 

   Hi,
  
   thank you for our suggestions. I am aware that I can solve my example 
 differently and that it might look not directly connected the proposal, but 
 well, it is an example just to show a single case and why it matters. :) I 
 did not want to discuss the example itself. Working around here would just 
 resolve a symptom.
  
   My point is the overall problem that would persist: A big part of 
 ExternalProject is to issue commands for predefined and custom steps. Those 
 commands are supposed to be executed by the shell/command line. According to 
 the documentation and the source code of ExternalProject, directory tokens 
 are mainly supposed to be replaced in commands. It is my understanding, that 
 it is a bug, if CMake isn't able to assemble these commands correctly. This 
 would include usage of the correct path style of the OS for shell/command 
 line commands. As directory tokens are replaced internally right before a 
 shell/command line command is assembled, I can't see why this would be kind 
 of API-breaking. You cannot interfere in your CMake code with these 
 internal replacements.
  
   Therefore I would still prefer my solution as it is pretty simple without 
 adding even more features to ExternalProject and in my opinion without 
 breaking code in the wild. It is a true bug fix instead of a feature request 
 for working directories, which is a different topic that just coincidentally 
 arised because of my specific example I guess. The features you described 
 wouldn't fix the actual bug.
  
   As you were not sure if my approach would even fix my problems: It does of 
 course and this is what I am currently doing and what I tested extensively 
 before creating the patch. :) Regarding your quote from the 
 add_custom_command documentation I can tell you that this is how things are 
 currently done in ExternalProject and always were as far as I know, for 
 example (from ExternalProject.cmake):
  
 add_custom_command(
   OUTPUT ${stamp_file}
   BYPRODUCTS ${byproducts}
   COMMENT ${comment}
   COMMAND ${command}
   COMMAND ${touch}
   DEPENDS ${depends}
   WORKING_DIRECTORY ${work_dir}
   VERBATIM
   )
  
   Best regards,
   Stefan
  
  
   -Original Message-
   From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On 
 Behalf Of James Johnston
   Sent: Donnerstag, 20. August 2015 15:37
   To: cmake-developers@cmake.org
   Subject: Re: [cmake-developers] ExternalProject: Use native paths as 
 substitute for directory tokens
  
-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
On Behalf Of Kislinskiy, Stefan
Sent: Thursday, August 20, 2015 09:02
To: David Cole
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as
substitute for directory tokens
   
Hi David,
   
Example excerpt (it is not possible to change the working directory
for
   the
CONFIGURE_COMMAND as it is fixed to the BUILD_DIR, which might not be
sufficient):
  
   This doesn't really directly have to do with your proposal, but what if an 
 option was added to change the working dir of the CONFIGURE_COMMAND?  E.g.
   WORKING_DIRECTORY_CONFIGURE.  And suppose you'd have it recognize the 
 various tags like SOURCE_DIR, etc.  This might be useful to add to other 
 steps as well, and would be more portable than your solution which is using 
 cmd.exe-specific commands.  You'd want to audit for any resulting breakage 
 (e.g. does ExternalProject make assumptions that the working directory of 
 CONFIGURE is always the binary dir? - e.g. a relative path being used 
 somewhere.  And probably only allow specification of 
 WORKING_DIRECTORY_CONFIGURE if a CONFIGURE_COMMAND was also specified, as the 
 built-in commands certainly assume the default working dir.)
  
   In your situation though, I'm not sure it's strictly needed.  From your 
 sample, it looks like you're building boost.  In your case what if you:
  
* Use ExternalProject_Add_Step to bootstrap.  You can specify a 
 WORKING_DIRECTORY here.  Note one problem: you can't do out of source build 
 of b2, which breaks user expectations.
* Then use ExternalProject_Add_Step to build Boost.
  
   Yes, using _Add_Step is somewhat of a workaround, but in this case, I've 
 found it wasn't much of a burden at all.  In fact the only case I can think 
 of where it WOULD be a burden would be if the configure step is CMake.  But 
 then you wouldn't need to change the working directory; changing it would 
 break CMake.  In practice nobody will want

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

[Kislinskiy, Stefan]

Hi,

thank you for our suggestions. I am aware that I can solve my example 
differently and that it might look not directly connected the proposal, but 
well, it is an example just to show a single case and why it matters. :) I did 
not want to discuss the example itself. Working around here would just resolve 
a symptom.

My point is the overall problem that would persist: A big part of 
ExternalProject is to issue commands for predefined and custom steps. Those 
commands are supposed to be executed by the shell/command line. According to 
the documentation and the source code of ExternalProject, directory tokens are 
mainly supposed to be replaced in commands. It is my understanding, that it is 
a bug, if CMake isn't able to assemble these commands correctly. This would 
include usage of the correct path style of the OS for shell/command line 
commands. As directory tokens are replaced internally right before a 
shell/command line command is assembled, I can't see why this would be kind of 
API-breaking. You cannot interfere in your CMake code with these internal 
replacements.

Therefore I would still prefer my solution as it is pretty simple without 
adding even more features to ExternalProject and in my opinion without breaking 
code in the wild. It is a true bug fix instead of a feature request for working 
directories, which is a different topic that just coincidentally arised because 
of my specific example I guess. The features you described wouldn't fix the 
actual bug.

As you were not sure if my approach would even fix my problems: It does of 
course and this is what I am currently doing and what I tested extensively 
before creating the patch. :) Regarding your quote from the add_custom_command 
documentation I can tell you that this is how things are currently done in 
ExternalProject and always were as far as I know, for example (from 
ExternalProject.cmake):

  add_custom_command(
OUTPUT ${stamp_file}
BYPRODUCTS ${byproducts}
COMMENT ${comment}
COMMAND ${command}
COMMAND ${touch}
DEPENDS ${depends}
WORKING_DIRECTORY ${work_dir}
VERBATIM
)

Best regards,
Stefan


-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
James Johnston
Sent: Donnerstag, 20. August 2015 15:37
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute 
for directory tokens

 -Original Message-
 From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
 On Behalf Of Kislinskiy, Stefan
 Sent: Thursday, August 20, 2015 09:02
 To: David Cole
 Cc: cmake-developers@cmake.org
 Subject: Re: [cmake-developers] ExternalProject: Use native paths as 
 substitute for directory tokens
 
 Hi David,
 
 Example excerpt (it is not possible to change the working directory 
 for
the
 CONFIGURE_COMMAND as it is fixed to the BUILD_DIR, which might not be
 sufficient):

This doesn't really directly have to do with your proposal, but what if an 
option was added to change the working dir of the CONFIGURE_COMMAND?  E.g.
WORKING_DIRECTORY_CONFIGURE.  And suppose you'd have it recognize the various 
tags like SOURCE_DIR, etc.  This might be useful to add to other steps as 
well, and would be more portable than your solution which is using 
cmd.exe-specific commands.  You'd want to audit for any resulting breakage 
(e.g. does ExternalProject make assumptions that the working directory of 
CONFIGURE is always the binary dir? - e.g. a relative path being used 
somewhere.  And probably only allow specification of 
WORKING_DIRECTORY_CONFIGURE if a CONFIGURE_COMMAND was also specified, as the 
built-in commands certainly assume the default working dir.)

In your situation though, I'm not sure it's strictly needed.  From your sample, 
it looks like you're building boost.  In your case what if you:

 * Use ExternalProject_Add_Step to bootstrap.  You can specify a 
WORKING_DIRECTORY here.  Note one problem: you can't do out of source build of 
b2, which breaks user expectations.
 * Then use ExternalProject_Add_Step to build Boost.

Yes, using _Add_Step is somewhat of a workaround, but in this case, I've found 
it wasn't much of a burden at all.  In fact the only case I can think of where 
it WOULD be a burden would be if the configure step is CMake.  But then you 
wouldn't need to change the working directory; changing it would break CMake.  
In practice nobody will want to change WORKING_DIRECTORY unless it's a custom 
command and then it's easy to use _Add_Step anyway.
That said, it might still be considered a little undesired and so maybe my 
proposal above would be a better way to handle it.

Corrections from maintainers and others on the above commentary are welcome...

 
 set(bootstrap_cmd SOURCE_DIR/bootstrap${shell_ext}
 ${bootstrap_toolset})
 
 if(WIN32)
   set(bootstrap_cmd pushd SOURCE_DIR COMMAND ${bootstrap_cmd} 
 COMMAND popd)
 endif()
 
 ExternalProject_Add(Boost

[cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

[Kislinskiy, Stefan]

Hi,

I would like to contribute a fix regarding directory tokens (e.g. SOURCE_DIR) 
in the ExternalProject module. These tokens are replaced by their matching 
target property value _EP_${dir}. However, the path substitutes are not 
converted to native path style which makes it impossible to use directory 
tokens in some Windows commands like pushd, as these commands are not able to 
handle forward slashes. I attached a tiny patch which simply calls 
file(TO_NATIVE_PATH) before replacing directory tokens.

Best regards,
Stefan Kislinskiy

external-project-native-dir-tokens.patch
Description: external-project-native-dir-tokens.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