Re: [cmake-developers] Preferred case for macro names?

2018-11-13 Thread David Cole via cmake-developers
I would just like to point out that some modules (ExternalData,
ExternalProject, to name two specific examples) adopted the convention
to prefix all their provided function names with the module name and
an underscore: for example, ExternalProject_Add and
ExternalData_Expand_Arguments.

These functions adopt a mixed-case function naming convention, since
the module name is mixed case, and since module names are file names,
and some file systems have case sensitive file names .. they
should stay that way regardless of any convention you may like to try
to adopt elsewhere.


David C.

On Tue, Nov 13, 2018 at 5:36 AM Eric Noulard  wrote:
>
>
>
> Le mar. 13 nov. 2018 à 10:41, Marc CHEVRIER  a écrit 
> :
>>
>> I agree as well that trying to distinguish macros from functions is not a 
>> good idea because functions can act in the same way as macros (i.e. changing 
>> calling environment) but with a better control over environment changes 
>> (changes are done explicitly by using 'set(... PARENT_SCOPE)').
>>
>> so also +1 for lower case for every function, macro or builtin. And good 
>> point to standardize  macro or function OPTION to UPPERCASE.
>>
>> Now, for variables, the problem is a bit different because they are case 
>> sensitive: 'set(my_var ...)' and 'set (MY_VAR ...)' will create two 
>> different variables.
>
>
> Yes damn right.
>
>>
>> My personal tendency is to use lower case for local variables and upper case 
>> for global variables. May be we can normalize variables to upper case 
>> regarding global variables used by CMake itself (which is globally the 
>> current rule).
>
>
> Having a convention for local is nice and I tend to prefix with _ (single or 
> double) variables that should be local.
> lowercasing locals is fine too, however I think that enforcing casing on 
> "user-defined" variable may not be desirable, concerning CMAKE_ CTEST_ and 
> CPACK_
> I guess they already are all UPPERCASE so we may stick with this as a 
> convention?
>
> A small quote to the cmake-format 
> (https://github.com/cheshirekow/cmake_format) tool which is trying to 
> beautify CMakeLists.txt, I'm not using it on complex projects
> because it still has some issues but I find it otherwise useful.
>
>
> --
> Eric
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] Link element in C# project causing issues with binary dir

2018-06-29 Thread David Cole via cmake-developers
The code looks wrong like this, too:

You shouldn't strip the source directory from the path of the file
name unless the character after the source directory is "/" or "\\",
should you? If the thing you're trying to end up with is a path name
to the file under the source directory, then this is incorrect in this
case.

I'm guessing you have "layout-composer" and "layout-composer-build" as
sibling directories of each other?



On Fri, Jun 29, 2018 at 4:12 PM Robert Dailey  wrote:
>
> According to the code, the logic is wrong:
>
> void cmVisualStudio10TargetGenerator::GetCSharpSourceLink(
>   cmSourceFile const* sf, std::string& link)
> {
>   std::string f = sf->GetFullPath();
>   if (!this->InSourceBuild) {
> const std::string stripFromPath =
>   this->Makefile->GetCurrentSourceDirectory();
> if (f.find(stripFromPath) != std::string::npos) {
>   link = f.substr(stripFromPath.length() + 1);
>   if (const char* l = sf->GetProperty("VS_CSHARP_Link")) {
> link = l;
>   }
>   ConvertToWindowsSlash(link);
> }
>   }
> }
>
>
> It's checking if the whole binary dir is rooted where source dir is,
> instead it should be checking each file to see if they are descendents
> of CMAKE_BINARY_DIR, and if so, use the , otherwise don't use
> it. This allows  to be variable between files in the project.
>
> Does anyone know if there's already a function in CMake for checking
> if a file is in the CMAKE_BINARY_DIR? Or do I have to write my own
> code for that check?
>
> On Fri, Jun 29, 2018 at 3:08 PM, Robert Dailey  
> wrote:
> > When I use configure_file() to generate AssemblyInfo.cs, which I allow
> > to go to the CMAKE_CURRENT_BINARY_DIR, Visual Studio 2017 reports:
> >
> > Warning The file
> > 'E:\code\layout-composer-build\Properties\AssemblyInfo.cs' could not
> > be added to the project.  Cannot add a link to the file
> > E:\code\layout-composer-build\Properties\AssemblyInfo.cs. This file is
> > within the project directory tree.
> >
> > When I define a target using C# language, it adds this for files under
> > the same directory as the generated CSPROJ file:
> >
> > 
> >   build\Properties\AssemblyInfo.cs
> > 
> >
> > The CSPROJ file is located: 
> > E:\code\layout-composer-build\LayoutComposer.csproj
> >
> > Is there a way to make the  element not needed in this scenario?
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] CMake build with static crt and static QtDialog not linking

2018-02-13 Thread David Cole via cmake-developers
I had a project where I had to do this in the main.cpp file to get it
to link with static Qt on Windows:

#ifdef _WIN32
#ifdef QT_STATIC
Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin)
#endif
#endif

Those unresolved externals you posted look familiar... Does this fix it?


HTH,
David C.

On Tue, Feb 13, 2018 at 11:28 AM, Stuermer, Michael  SP/HZA-ZSEP
 wrote:
> I try to do a CMake build with static C runtime and a static Qt 5.10.0 build
> to avoid runtime errors when giving the binaries to colleagues. The Visual
> Studio version is 2017. AFAIK the official CMake builds already use this
> “full-static-build” scheme. However I end up with some linking errors of 137
> unresolved external symbols starting with
>
>
>
> unresolved external symbol __imp_OpenThemeData referenced in function
> "public: virtual void __cdecl QVistaBackButton::paintEvent
>
>
>
> and ending with
>
>
>
> unresolved external symbol NetApiBufferFree referenced in function "public:
> static bool __cdecl QFileSystemEngine::uncListSharesOnServer
>
>
>
> Are there some tricks I have to do to get this working? I changed all /MD
> flags manually to /MT, but nothing else so far.
>
>
>
> PS: I’m not sure how the mailing list is handled compared to the gitlab
> instance. Would this be something I should open an issue for? I personally
> do not see it as an issue (which means “something has to be changed in the
> code” for me). Or is the mailing list more or less a leftover from
> before-gitlab times?
>
>
>
> Best regards,
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] CTest script and many subprojects

2017-09-01 Thread David Cole via cmake-developers
I think your analysis is correct.

You could try doing a ctest_submit after each ctest_test call. Not
sure if you could get "correct" results with that technique. I run
some scripts that do something similar without subproject involved,
and it mostly works, but messes up the +/- tests passed and failed
since last submission data on the instance of CDash I'm using.

If you would like it to work differently than it presently does, it
would probably involve some changes to ctest. Making it do what you
want it to do and becoming a contributor is probably the quickest way
to achieve that.


HTH,
David C.



On Fri, Sep 1, 2017 at 2:36 PM, Wouter Klouwen
 wrote:
> Hi all,
>
> I've been having some success with CTest and am interested in using
> CDash as well.
>
> In order to generate some nice output, sub projects seem to be the best
> way of presenting the data in CDash for our setup. This setup is perhaps
> summed up by having one projects that contains a few hundred projects.
> Most of these "sub projects" are normal CMake projects.
>
> Now, in the normal build, we have a `check` target. This is powered by
> having tests added with add_test() and this check target invokes CTest
> with a script that contains the setting of the SubProject property.
>
> This produces the expected Test.xml with the SubProject tag. When
> submitting these to CDash, it produces the right subproject view and the
> expected aggregate view.
>
> The next step is that we have code on devices for which we cross compile
> and we want to use the same mechanism here in order to execute tests
> when installed on our target devices.
>
> Before I started the CDash work, I was able to generate CTest files
> which contain the add_test() and set_tests_properties() in order to run
> the tests on the devices. This was then invoked with the
> DartConfiguration.tcl and ctest -T Test
>
> Perhaps not ideal as it involves generated many CTestTestfile.cmakes,
> but this was able to execute the several hundreds of tests with the
> appropriate load balancing and produce one giant Test.xml.
>
> In order to switch to generate Test.xml files with SubProject tags this
> mechanism needs to be switched to using a CTest script.
>
> As SubProject is a global property, I assume this needs to be unique for
> each invocation of ctest_test().
> Unfortunately putting multiple ctest_test() calls in one CTest script
> seems to result in one Test.xml, which is the last project run. The test
> of the output is overwritten.
>
> It seems the only way I can make this work is by having a script which
> effectively creates a new CTest script for each subproject, and moves
> the produced Test.xml out of the way for the next run.
> Is this right?
>
> I hope this all makes sense.
>
> Thanks in advance,
> W
> This transmission contains information that may be confidential and contain
> personal views which are not necessarily those of YouView TV Ltd. YouView TV
> Ltd (Co No:7308805) is a limited liability company registered in England and
> Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower
> Thames Street, London, EC3R 6YT. For details see our web site at
> http://www.youview.com
> --
>
> 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] [CMake] Debugging find_package() search behavior?

2017-08-29 Thread David Cole via cmake-developers
Sorry for the mis-statement. I stand corrected.

However, it is true that there are many find modules with some
differences in approach, and if you are using one, you need to read up
on the individual documentation of that particular find module.
Especially if you need to know how to tell it how to find the exact
one you already know you have...




On Tue, Aug 29, 2017 at 11:49 AM, Brad King <brad.k...@kitware.com> wrote:
> On 08/29/2017 11:33 AM, David Cole wrote:
>> That's correct:
>>
>> find modules do what they want, and most do not pay attention to
>> CMAKE_PREFIX_PATH.
>
> CMAKE_PREFIX_PATH *is* used by find modules.
>
> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH.
> See the documentation of find_library, find_path, etc. for details.
> Each command searches an appropriate `/` where ``
> is based on the kind of command doing the searching.
>
> -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] [cmake-developers] Debugging find_package() search behavior?

2017-08-29 Thread David Cole via CMake
Sorry for the mis-statement. I stand corrected.

However, it is true that there are many find modules with some
differences in approach, and if you are using one, you need to read up
on the individual documentation of that particular find module.
Especially if you need to know how to tell it how to find the exact
one you already know you have...




On Tue, Aug 29, 2017 at 11:49 AM, Brad King <brad.k...@kitware.com> wrote:
> On 08/29/2017 11:33 AM, David Cole wrote:
>> That's correct:
>>
>> find modules do what they want, and most do not pay attention to
>> CMAKE_PREFIX_PATH.
>
> CMAKE_PREFIX_PATH *is* used by find modules.
>
> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH.
> See the documentation of find_library, find_path, etc. for details.
> Each command searches an appropriate `/` where ``
> is based on the kind of command doing the searching.
>
> -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


Re: [CMake] [cmake-developers] Debugging find_package() search behavior?

2017-08-29 Thread David Cole via CMake
That's correct:

find modules do what they want, and most do not pay attention to
CMAKE_PREFIX_PATH.

It's better to use a config file, but when you have to use a find
module, you have to dig in and figure out the right way to use each
one.



On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> I think the discrepancy here might be config vs module find mode. The
> documentation I linked seems to be for config mode only, however I'm
> utilizing the CMake-shipped FindZLIB.cmake module to find this
> particular library. Does this offer no guarantees on how
> CMAKE_PREFIX_PATH is used?
>
> On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey
> <rcdailey.li...@gmail.com> wrote:
>> What I'm hoping for is that find_package() follows the rules it
>> documents here:
>> https://cmake.org/cmake/help/v3.6/command/find_package.html
>>
>> Specifically, it states it searches these paths (and that  is
>> treated case-insensitive):
>>
>> /   (W)
>> /(cmake|CMake)/ (W)
>> /*/   (W)
>> /*/(cmake|CMake)/ (W)
>> /(lib/|lib|share)/cmake/*/  (U)
>> /(lib/|lib|share)/*/(U)
>> /(lib/|lib|share)/*/(cmake|CMake)/  (U)
>>
>> If this is true, then the 3rd one from the top should be a match,
>> because  is set to:
>>
>> E:/code/frontend/msvc_2015/third_party/installed
>>
>> And  is set to ZLIB in find_package() first argument, so it
>> should be adding that to the end.
>>
>> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
>> ("installed") because I have other libraries that get installed in
>> that directory, each with their own directory to contain their
>> installation files. If find_package() is appending  to 
>> like it says it should, it should find each one of them without
>> switching the value of CMAKE_PREFIX_PATH.
>>
>> Am I misunderstanding something?
>>
>>
>> On Tue, Aug 29, 2017 at 10:06 AM, David Cole <dlrd...@aol.com> wrote:
>>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>>>
>>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
>>> <rcdailey.li...@gmail.com> wrote:
>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
>>>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>>
>>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>>>>> drive letters on Windows.
>>>>>
>>>>> Oops, sent too soon.
>>>>>
>>>>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for 
>>>>> cross-compiling
>>>>> to re-root paths like `/usr` into some prefix on the host.
>>>>>
>>>>> -Brad
>>>>
>>>> Ok but even if I remove that, find_package() still isn't working..
>>>> --
>>>>
>>>> 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
-- 

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


Re: [cmake-developers] [CMake] Debugging find_package() search behavior?

2017-08-29 Thread David Cole via cmake-developers
That's correct:

find modules do what they want, and most do not pay attention to
CMAKE_PREFIX_PATH.

It's better to use a config file, but when you have to use a find
module, you have to dig in and figure out the right way to use each
one.



On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> I think the discrepancy here might be config vs module find mode. The
> documentation I linked seems to be for config mode only, however I'm
> utilizing the CMake-shipped FindZLIB.cmake module to find this
> particular library. Does this offer no guarantees on how
> CMAKE_PREFIX_PATH is used?
>
> On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey
> <rcdailey.li...@gmail.com> wrote:
>> What I'm hoping for is that find_package() follows the rules it
>> documents here:
>> https://cmake.org/cmake/help/v3.6/command/find_package.html
>>
>> Specifically, it states it searches these paths (and that  is
>> treated case-insensitive):
>>
>> /   (W)
>> /(cmake|CMake)/ (W)
>> /*/   (W)
>> /*/(cmake|CMake)/ (W)
>> /(lib/|lib|share)/cmake/*/  (U)
>> /(lib/|lib|share)/*/(U)
>> /(lib/|lib|share)/*/(cmake|CMake)/  (U)
>>
>> If this is true, then the 3rd one from the top should be a match,
>> because  is set to:
>>
>> E:/code/frontend/msvc_2015/third_party/installed
>>
>> And  is set to ZLIB in find_package() first argument, so it
>> should be adding that to the end.
>>
>> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
>> ("installed") because I have other libraries that get installed in
>> that directory, each with their own directory to contain their
>> installation files. If find_package() is appending  to 
>> like it says it should, it should find each one of them without
>> switching the value of CMAKE_PREFIX_PATH.
>>
>> Am I misunderstanding something?
>>
>>
>> On Tue, Aug 29, 2017 at 10:06 AM, David Cole <dlrd...@aol.com> wrote:
>>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>>>
>>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
>>> <rcdailey.li...@gmail.com> wrote:
>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
>>>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>>
>>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>>>>> drive letters on Windows.
>>>>>
>>>>> Oops, sent too soon.
>>>>>
>>>>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for 
>>>>> cross-compiling
>>>>> to re-root paths like `/usr` into some prefix on the host.
>>>>>
>>>>> -Brad
>>>>
>>>> Ok but even if I remove that, find_package() still isn't working..
>>>> --
>>>>
>>>> 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
-- 

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] [cmake-developers] Debugging find_package() search behavior?

2017-08-29 Thread David Cole via CMake
Is there a ZLIBConfig.cmake file which find_package is searching for?
(i.e. -- somewhere under that directory does that file exist?) On
Windows the case won't matter, but on Linux, a find_package(ZLIB will
expect a case-sensitive match on a ZLIBConfig.cmake file.

If ZLIBConfig.cmake exists, it needs to exist in one of the locations
on that find_package documentation snippet you sent. If it's not
directly in the "zlib" folder, or one of the other folders listed,
then it won't be found. The directory it is in, or something matching
one of those in the list needs to be included in your
CMAKE_PREFIX_PATH.


If that file does not exist, then the CMake FindZLIB.cmake module will
be used in an attempt to find your zlib... And the help for that
speaks of setting a ZLIB_ROOT var if you want to direct it to find a
given zlib. See the "HINTS" section here:

https://cmake.org/cmake/help/v3.6/module/FindZLIB.html#hints


One more hint regarding CMAKE_PREFIX_PATH : despite its name, it is a
**list** of paths, and you can use multiple semi-colon separated
values if necessary. So, if appending "/zlib" works, then you could
always find zlib and all your other stuff too by using two directories
as your CMAKE_PREFIX_PATH value.


HTH,
David C.



On Tue, Aug 29, 2017 at 11:11 AM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> What I'm hoping for is that find_package() follows the rules it
> documents here:
> https://cmake.org/cmake/help/v3.6/command/find_package.html
>
> Specifically, it states it searches these paths (and that  is
> treated case-insensitive):
>
> /   (W)
> /(cmake|CMake)/ (W)
> /*/   (W)
> /*/(cmake|CMake)/ (W)
> /(lib/|lib|share)/cmake/*/  (U)
> /(lib/|lib|share)/*/(U)
> /(lib/|lib|share)/*/(cmake|CMake)/  (U)
>
> If this is true, then the 3rd one from the top should be a match,
> because  is set to:
>
> E:/code/frontend/msvc_2015/third_party/installed
>
> And  is set to ZLIB in find_package() first argument, so it
> should be adding that to the end.
>
> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
> ("installed") because I have other libraries that get installed in
> that directory, each with their own directory to contain their
> installation files. If find_package() is appending  to 
> like it says it should, it should find each one of them without
> switching the value of CMAKE_PREFIX_PATH.
>
> Am I misunderstanding something?
>
>
> On Tue, Aug 29, 2017 at 10:06 AM, David Cole <dlrd...@aol.com> wrote:
>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>>
>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
>> <rcdailey.li...@gmail.com> wrote:
>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
>>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>
>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>>>> drive letters on Windows.
>>>>
>>>> Oops, sent too soon.
>>>>
>>>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for 
>>>> cross-compiling
>>>> to re-root paths like `/usr` into some prefix on the host.
>>>>
>>>> -Brad
>>>
>>> Ok but even if I remove that, find_package() still isn't working..
>>> --
>>>
>>> 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
-- 

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


Re: [cmake-developers] [CMake] Debugging find_package() search behavior?

2017-08-29 Thread David Cole via cmake-developers
Is there a ZLIBConfig.cmake file which find_package is searching for?
(i.e. -- somewhere under that directory does that file exist?) On
Windows the case won't matter, but on Linux, a find_package(ZLIB will
expect a case-sensitive match on a ZLIBConfig.cmake file.

If ZLIBConfig.cmake exists, it needs to exist in one of the locations
on that find_package documentation snippet you sent. If it's not
directly in the "zlib" folder, or one of the other folders listed,
then it won't be found. The directory it is in, or something matching
one of those in the list needs to be included in your
CMAKE_PREFIX_PATH.


If that file does not exist, then the CMake FindZLIB.cmake module will
be used in an attempt to find your zlib... And the help for that
speaks of setting a ZLIB_ROOT var if you want to direct it to find a
given zlib. See the "HINTS" section here:

https://cmake.org/cmake/help/v3.6/module/FindZLIB.html#hints


One more hint regarding CMAKE_PREFIX_PATH : despite its name, it is a
**list** of paths, and you can use multiple semi-colon separated
values if necessary. So, if appending "/zlib" works, then you could
always find zlib and all your other stuff too by using two directories
as your CMAKE_PREFIX_PATH value.


HTH,
David C.



On Tue, Aug 29, 2017 at 11:11 AM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> What I'm hoping for is that find_package() follows the rules it
> documents here:
> https://cmake.org/cmake/help/v3.6/command/find_package.html
>
> Specifically, it states it searches these paths (and that  is
> treated case-insensitive):
>
> /   (W)
> /(cmake|CMake)/ (W)
> /*/   (W)
> /*/(cmake|CMake)/ (W)
> /(lib/|lib|share)/cmake/*/  (U)
> /(lib/|lib|share)/*/(U)
> /(lib/|lib|share)/*/(cmake|CMake)/  (U)
>
> If this is true, then the 3rd one from the top should be a match,
> because  is set to:
>
> E:/code/frontend/msvc_2015/third_party/installed
>
> And  is set to ZLIB in find_package() first argument, so it
> should be adding that to the end.
>
> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
> ("installed") because I have other libraries that get installed in
> that directory, each with their own directory to contain their
> installation files. If find_package() is appending  to 
> like it says it should, it should find each one of them without
> switching the value of CMAKE_PREFIX_PATH.
>
> Am I misunderstanding something?
>
>
> On Tue, Aug 29, 2017 at 10:06 AM, David Cole <dlrd...@aol.com> wrote:
>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>>
>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
>> <rcdailey.li...@gmail.com> wrote:
>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
>>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>
>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>>>> drive letters on Windows.
>>>>
>>>> Oops, sent too soon.
>>>>
>>>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for 
>>>> cross-compiling
>>>> to re-root paths like `/usr` into some prefix on the host.
>>>>
>>>> -Brad
>>>
>>> Ok but even if I remove that, find_package() still isn't working..
>>> --
>>>
>>> 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
-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] [CMake] Debugging find_package() search behavior?

2017-08-29 Thread David Cole via cmake-developers
Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?

On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
 wrote:
> On Tue, Aug 29, 2017 at 9:56 AM, Brad King  wrote:
>> On 08/29/2017 10:55 AM, Brad King wrote:
>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
 CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
 CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>
>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>> drive letters on Windows.
>>
>> Oops, sent too soon.
>>
>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for cross-compiling
>> to re-root paths like `/usr` into some prefix on the host.
>>
>> -Brad
>
> Ok but even if I remove that, find_package() still isn't working..
> --
>
> 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
-- 

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] [cmake-developers] Debugging find_package() search behavior?

2017-08-29 Thread David Cole via CMake
Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?

On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
 wrote:
> On Tue, Aug 29, 2017 at 9:56 AM, Brad King  wrote:
>> On 08/29/2017 10:55 AM, Brad King wrote:
>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
 CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
 CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>
>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>> drive letters on Windows.
>>
>> Oops, sent too soon.
>>
>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for cross-compiling
>> to re-root paths like `/usr` into some prefix on the host.
>>
>> -Brad
>
> Ok but even if I remove that, find_package() still isn't working..
> --
>
> 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
-- 

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


Re: [cmake-developers] Future of ccmake and cmake-gui

2017-08-16 Thread David Cole via cmake-developers
This is great to see CMake continuing to evolve like this!

What's next, a web page CMake UI connected to cmake server instances
on multiple platforms? ;-)



On Wed, Aug 16, 2017 at 6:05 PM, Daniel Pfeifer  wrote:
> On Wed, Aug 16, 2017 at 6:16 PM, Eric Wing  wrote:
>>
>> On 8/15/17, Daniel Pfeifer  wrote:
>> > Hi,
>> >
>> > With !977 merged, it is possible to base ccmake and cmake-gui on top of
>> > the
>> > cmake server.
>> > For demonstration, I copied the contents of the Source/CursesDialog
>> > directory and added a proxy implementation of the classes `cmake` and
>> > `cmState`. The result is 100% compatible with `ccmake`. The same would
>> > be
>> > possible with cmake-gui.
>> >
>> > Shall we proceed in this direction?
>> >
>> > To make the server available everywhere, we should backport the code
>> > from
>> > C++14 to C++11. I think this is limited to replacing `std::make_shared`.
>> >
>> > For cmake-gui, the proxies could use Qt functionality (QProcess,
>> > QJsonDocument, etc.). As a result, cmake-gui would not have any build
>> > dependencies apart from Qt.
>> >
>> > It might be worth considering to move ccmake and cmake-gui to their own
>> > repositories.
>> >
>> > Cheers, Daniel
>> >
>>
>> If this is a new rewrite...
>
>
> It is not. Both ccmake and cmake-gui use the use the `cmake` class as a
> facade to the cmakelib.
> In my prototype I re-implemented the `cmake` class as a client to the
> cmake-server using json-cpp and libuv.
> This allows separating ccmake and cmake-gui from the cmakelib without
> further changes to the rest of the code.
>
> The same client implementation might be used for ccmake and cmake-gui, but
> cmake-gui might as well use Qt facilities instead.
>
>> I am not making a strong push for this, but I want to bring it up to
>> at least get people thinking about this... I am disturbed by the size
>> and complexity of Qt. My past experiences have not been good and I
>> find it a massive chore to get an environment setup (especially on Mac
>> and Windows...and building Qt on Raspberry Pi is a nightmare). And the
>> binary sizes are large. (I do ship CMake to my users and its size with
>> the GUI is non-trivial.)
>>
>> CMake's actual GUI isn't that complex. Have you considered something
>> lighter-weight?
>>
>> As one alternative, there is IUP:
>> http://webserver2.tecgraf.puc-rio.br/iup/
>> (it's from the same university that created Lua...in fact I think one
>> of the original authors of the white paper/project went on to become
>> one of the Lua authors.)
>>
>> IUP differs from Qt in that is is focused on wrapping native GUI
>> widgets (in constrast to Qt which creates its own non-native widgets).
>> Hence, the library is really small since it only depends on each
>> platform's native libraries. The core library is about 1MB. I just
>> ported (rewrote) a simple Qt based app to IUP. The Qt version was
>> almost 40MB. The IUP RAM usage is also many times smaller.
>>
>> It has native backends for Windows, GTK2, GTK3, Motif, Haiku. Because
>> it historically didn't have a Mac OS X backend, most people overlooked
>> it. However...I've been implementing a native Mac OS X backend. It's
>> not finished, but there is a lot implemented and I'm actually shipping
>> a simple app with it this week. Since CMake's GUI usage is also pretty
>> simple, I *think* there might already be enough implemented to do the
>> CMake-GUI...or it's close enough that I probably could finish those
>> needed features.
>>
>> Also, I implemented a CMake build system for IUP.
>>
>> IUP is MIT licensed.
>
>
> Sounds interesting.
>
>> Now IUP only does GUI (which is another reason it stays small), so you
>> will need to fill in the JSON and Process requirements. But there are
>> tons of JSON libraries. Off the top of my head, cJSON is a really
>> fast, tiny, and simple to use JSON library. It's a single C file and
>> header, so you can drop it right in the project. (Also MIT). It also
>> has a CMake build system if you really want it.
>>
>>
>>
>> And a cross-platform create process...those I've seen everywhere and
>> I've actually written my own too. I think Apache Runtime is only
>> measured in hundreds of kilobytes even with all the stuff you don't
>> need.
>> A quick Google search turned up this one C++ (MIT)
>> https://github.com/eidheim/tiny-process-library
>
>
> That would not be necessary. A cache editor build on IUP could use the same
> cmake client implementation as ccmake.
>
>> So IUP + some JSON + some Process should be around 1MB-2MB. This is in
>> contrast to the Qt frameworks I have right now in my CMake bundle for
>> Mac.
>>
>>
>> Anyway, I know this is going to be outside peoples' comfort-zone which
>> is why I'm not going to push hard on it. But in general, I would like
>> something smaller, easier to build, and lighter on system resources
>> (and real native GUIs generally provide a better user experience). So
>> I'm hoping 

Re: [CMake] CMake 3.9.0 Windows zip file shows wrong version

2017-08-08 Thread David Cole via CMake
I suspect you are running a different cmake, not the one you've unzipped.

Type "where cmake" instead of "cmake --version" and Windows will list
the directories where it finds an executable named cmake. The first
one it lists is the one it is running when you type "cmake
--version"...

If you want to force the one you've downloaded to run instead of that
one, you could **prepend** to the PATH instead of appending to it.


HTH,
David C.



On Mon, Aug 7, 2017 at 9:07 PM, Adam Getchell  wrote:
> Hi all,
>
> The CMake 3.9.0 Windows zip file gives the wrong version. Here’s a snippet
> from my AppVeyor logs [1]:
>
> set CMAKE_URL="https://cmake.org/files/v3.9/cmake-3.9.0-win64-x64.zip;
> appveyor DownloadFile %CMAKE_URL% -FileName cmake.zip
> Downloading cmake.zip (25,944,520 bytes)...100%
> 7z x cmake.zip -oC:\projects\dev
> 7-Zip [64] 16.04 : Copyright (c) 1999-2016 Igor Pavlov : 2016-10-04
> Scanning the drive for archives:
> 1 file, 25944520 bytes (25 MiB)
> Extracting archive: cmake.zip
> --
> Path = cmake.zip
> Type = zip
> Physical Size = 25944520
> Everything is Ok
> Folders: 90
> Files: 4922
> Size: 66584952
> Compressed: 25944520
> set PATH=%PATH%;C:\projects\dev\cmake\bin
> cmake --version
> cmake version 3.8.2
> CMake suite maintained and supported by Kitware (kitware.com/cmake).
>
> [1] https://ci.appveyor.com/project/acgetchell/cdt-plusplus
> --
> Adam Getchell
> https://keybase.io/adamgetchell
>
>
> --
>
> 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
-- 

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

Re: [CMake] What is the default build type?

2017-08-02 Thread David Cole via CMake
Yes, your code is a good example Marcus. It was one of the previous
suggestions on this thread which had example code setting
CMAKE_CONFIGURATION_TYPES.

I would recommend against setting this variable because in some places
in CMake code, it is used as an approximate proxy for whether or not a
multi-configuration generator is being used.


For a few examples, see the CMake code base itself:

$ git grep CMAKE_CONFIGURATION_TYPES | grep -Ev
"Auxiliary/vim/syntax/cmake.vim|Help/|Tests/"

CMakeCPack.cmake:  if(CMAKE_CONFIGURATION_TYPES)
Modules/CMakeExpandImportedTargets.cmake:#
${CMAKE_CONFIGURATION_TYPES} if set, otherwise ${CMAKE_BUILD_TYPE}.
Modules/CMakeExpandImportedTargets.cmake:  if(CMAKE_CONFIGURATION_TYPES)
Modules/CMakeExpandImportedTargets.cmake: list(GET
CMAKE_CONFIGURATION_TYPES 0 CEIT_CONFIGURATION)
Modules/CTestTargets.cmake:if(CMAKE_CONFIGURATION_TYPES)
Modules/DeployQt4.cmake:if(configurations AND
(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE))
Modules/DeployQt4.cmake:if(CMAKE_CONFIGURATION_TYPES
OR CMAKE_BUILD_TYPE)
Modules/ExternalProject.cmake:  if(CMAKE_CONFIGURATION_TYPES)
Modules/ExternalProject.cmake:if(CMAKE_CONFIGURATION_TYPES)
Modules/ExternalProject.cmake:  if(CMAKE_CONFIGURATION_TYPES)
Modules/ExternalProject.cmake:if(CMAKE_CONFIGURATION_TYPES)
Modules/ExternalProject.cmake:  foreach(cfg ${CMAKE_CONFIGURATION_TYPES})
Modules/FindBoost.cmake:  if(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
Modules/FindCUDA.cmake:# Makefile and similar generators don't define
CMAKE_CONFIGURATION_TYPES, so we
Modules/FindCUDA.cmake:set(CUDA_configuration_types
${CMAKE_CONFIGURATION_TYPES} ${CMAKE_BUILD_TYPE} Debug MinSizeRel
Release RelWithDebInfo)
Modules/FindQt4.cmake:if (CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
Modules/SelectLibraryConfigurations.cmake:   (
CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE ) )
Source/cmGlobalVisualStudio7Generator.cxx:  if
(!mf->GetDefinition("CMAKE_CONFIGURATION_TYPES")) {
Source/cmGlobalVisualStudio7Generator.cxx:
"CMAKE_CONFIGURATION_TYPES",
"Debug;Release;MinSizeRel;RelWithDebInfo",
Source/cmGlobalXCodeGenerator.cxx:  if
(!mf->GetDefinition("CMAKE_CONFIGURATION_TYPES")) {
Source/cmGlobalXCodeGenerator.cxx:  "CMAKE_CONFIGURATION_TYPES",
"Debug;Release;MinSizeRel;RelWithDebInfo",
Source/cmGlobalXCodeGenerator.cxx:
this->CurrentMakefile->GetRequiredDefinition("CMAKE_CONFIGURATION_TYPES");
Source/cmMakefile.cxx:
this->GetDefinition("CMAKE_CONFIGURATION_TYPES")) {
Utilities/Release/WiX/CMakeLists.txt:if(CMAKE_CONFIGURATION_TYPES)





On Wed, Aug 2, 2017 at 2:42 PM, Marcus D. Hanwell
<marcus.hanw...@kitware.com> wrote:
> On Wed, Aug 2, 2017 at 1:32 PM, David Cole <dlrd...@aol.com> wrote:
>> Very cool, Marcus. Thanks for the blog post.
>>
>> Florian, when you "message(${CMAKE_CONFIGURATION_TYPES})" it is empty
>> because you are using a single-configuration CMake generator. Only
>> Visual Studio and Xcode (and possibly other) **multi** config
>> generators have a list of values in CMAKE_CONFIGURATION_TYPES.
>> Contrary to the previous recommendation, I would NOT recommend setting
>> it to a list in a single configuration generator. If you're using a
>> multi-config generator, you can set up a subset for it to use with
>> this, but in a single config generator, this variable SHOULD be empty,
>> and you should not give it contents in that case.
>>
> Terrible English, try number two... Why would you not recommend
> setting it, and what do you mean by it? I was not setting
> CMAKE_CONFIGURATION_TYPES to anything, but the CMAKE_BUILD_TYPE
> property is manipulated to offer the list, and then the
> CMAKE_BUILD_TYPE variable is populated if it is empty in my example.
-- 

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


Re: [CMake] What is the default build type?

2017-08-02 Thread David Cole via CMake
Very cool, Marcus. Thanks for the blog post.

Florian, when you "message(${CMAKE_CONFIGURATION_TYPES})" it is empty
because you are using a single-configuration CMake generator. Only
Visual Studio and Xcode (and possibly other) **multi** config
generators have a list of values in CMAKE_CONFIGURATION_TYPES.
Contrary to the previous recommendation, I would NOT recommend setting
it to a list in a single configuration generator. If you're using a
multi-config generator, you can set up a subset for it to use with
this, but in a single config generator, this variable SHOULD be empty,
and you should not give it contents in that case.


HTH,
David C.



On Wed, Aug 2, 2017 at 11:55 AM, Marcus D. Hanwell
 wrote:
> On Wed, Aug 2, 2017 at 3:03 AM, Bo Zhou  wrote:
>>
>> It depends on the Generator.
>>
>> To the Makefile, the actual type was controlled by the compiler options.
>> If you don't specific any type, usually it means non-debug and
>> non-optimization because the CMAKE_CXX_FLAGS is empty as default. This is
>> critical, so usually people should specific the actual type they want to
>> build.
>>
>> To the generator of the IDE, such as Visual Studio and Xcode, the
>> CMAKE_BUILD_TYPE doesn't make sense but we have to use
>> CMAKE_CONFIGURATION_TYPES, then CMake will create the several configuration
>> sets for the IDE from the CMAKE_C|CXX_FLAGS_{CONFIG} .
>
>
> This thread inspired me to write up how we have been doing it in some of the
> projects I work on for quite a while now,
>
> https://blog.kitware.com/cmake-and-the-default-build-type/
>
> It certainly isn't the only way, but it provides an easy path to ensure
> things show up in the GUIs, respect build types passed in, etc.
>
> --
>
> 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
-- 

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


Re: [CMake] Source is not rebuild when header changes

2017-08-01 Thread David Cole via CMake
And in your file "src/CMakeLists.txt" do you add
"${CMAKE_CURRENT_SOURCE_DIR}" (or anything else which resolves to the
"src" directory) to your include directories?

The line which includes the header is
#include "mapping/..."
but there is no local subdirectory "mapping" relative to that file
(which is down in the mapping/config dir)




On Tue, Aug 1, 2017 at 6:47 AM, Florian Lindner <mailingli...@xgm.de> wrote:
> Hi,
>
> Am 01.08.2017 um 18:32 schrieb David Cole via CMake:
>> What source files include the header?
>
> It's included by src/mapping/config/MappingConfiguration.cpp
>
> https://github.com/precice/precice/blob/develop/src/mapping/config/MappingConfiguration.cpp
>
> https://github.com/precice/precice/blob/develop/src/mapping/PetRadialBasisFctMapping.hpp
>
>> Is one of them listed as a file in your project?
>
> Yes, it's also in the CMakeFiles:
>
> % ll 
> build/cmake-debug/CMakeFiles/precice.dir/src/mapping/config/MappingConfiguration.cpp.o
>
> -rw-r--r-- 1 florian florian 1517472  1. Aug 15:08
> build/cmake-debug/CMakeFiles/precice.dir/src/mapping/config/MappingConfiguration.cpp.o
>
>> Does the **including** file exist at CMake configure time, or is it
>> generated later by a build step?
>
> No, it's a standard plain file.
>
>> What do the lines of code that include the header look like?
>
> #include "mapping/PetRadialBasisFctMapping.hpp"
>
>>
>> CMake uses its own analysis of the source files to determine the
>> depends information, since it needs to generate it without invoking
>> the compiler. This leads to a less-than-100% rate of correctness in
>> the depends information, although usually, it is misses "in the other
>> direction" due to depending on a header file which is included in some
>> conditionally compiled block. (So the typical problem is an extra
>> dependency, not a missing one...)
>
> The header file is (not the including file or the #include itself) is guarded 
> by a define
>
> #ifndef PRECICE_NO_PETSC
>
> which is not set. The build also contains the functionality which is guarded 
> thereof.
>
>> Perhaps passing along the includers and the exact lines and context of
>> being included will give us a hint about why the dependency is not
>> generated properly in your case.
>
> I'm happy to provide whatever information I can.
>
> If you want to download the entire source of the project, tell me. Right now 
> the CMake files are not yet in the
> repository, but I can create a branch and add them there.
>
> My CMake version is 3.8.2.
>
> Best,
> Florian
>
>
>>
>>
>>
>> On Tue, Aug 1, 2017 at 5:18 AM, Florian Lindner <mailingli...@xgm.de> wrote:
>>> Hello,
>>>
>>> on my project, which I'm currently testing with cmake, I just noticed, that 
>>> when I modify a header, the project is not
>>> rebuilt.
>>>
>>> The CMakeLists.txt in the root dir is here: https://pastebin.com/vfReTM1N
>>>
>>> The other CMakeLists.txt resides in root/src and lists all the source 
>>> (*.cpp) files using GLOBS and adds them to the
>>> parent scope:
>>>
>>> set (sourcesAllNoMain ${sourcesAllNoMain} PARENT_SCOPE)
>>> set (sourcesTests ${sourcesTests} PARENT_SCOPE)
>>> set (sourcesTarchTests ${sourcesTarchTests} PARENT_SCOPE)
>>>
>>>
>>> the questionable header file was not added recently, so I don't think its 
>>> related to the GLOBs.
>>>
>>> The header file is also not listed in depends.make file.
>>>
>>> What other information can I give?
>>>
>>> Thanks,
>>> Florian
>>> --
>>>
>>> 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
-- 

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


Re: [CMake] Source is not rebuild when header changes

2017-08-01 Thread David Cole via CMake
What source files include the header?
Is one of them listed as a file in your project?
Does the **including** file exist at CMake configure time, or is it
generated later by a build step?
What do the lines of code that include the header look like?

CMake uses its own analysis of the source files to determine the
depends information, since it needs to generate it without invoking
the compiler. This leads to a less-than-100% rate of correctness in
the depends information, although usually, it is misses "in the other
direction" due to depending on a header file which is included in some
conditionally compiled block. (So the typical problem is an extra
dependency, not a missing one...)

Perhaps passing along the includers and the exact lines and context of
being included will give us a hint about why the dependency is not
generated properly in your case.


HTH,
David C.




On Tue, Aug 1, 2017 at 5:18 AM, Florian Lindner  wrote:
> Hello,
>
> on my project, which I'm currently testing with cmake, I just noticed, that 
> when I modify a header, the project is not
> rebuilt.
>
> The CMakeLists.txt in the root dir is here: https://pastebin.com/vfReTM1N
>
> The other CMakeLists.txt resides in root/src and lists all the source (*.cpp) 
> files using GLOBS and adds them to the
> parent scope:
>
> set (sourcesAllNoMain ${sourcesAllNoMain} PARENT_SCOPE)
> set (sourcesTests ${sourcesTests} PARENT_SCOPE)
> set (sourcesTarchTests ${sourcesTarchTests} PARENT_SCOPE)
>
>
> the questionable header file was not added recently, so I don't think its 
> related to the GLOBs.
>
> The header file is also not listed in depends.make file.
>
> What other information can I give?
>
> Thanks,
> Florian
> --
>
> 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
-- 

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


Re: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0

2017-07-25 Thread David Cole via cmake-developers
Alan, you had said in your original post:

"Using find and xargs -0 grep I have looked in both 3.7.2 and 3.9.0
source code for any mention of CMAKE_Java_CREATE_SHARED_MODULE, and it
just does not exist."

Try searching for "_CREATE_SHARED_MODULE" instead... it's combined in code with 
the name of the language.

Just a hint about how to further the investigation. I'm curious what the result 
will be, but don't have time right now to dig in on something peripheral to my 
main to do list.


David C.


> On Jul 25, 2017, at 5:07 AM, Eric Noulard  wrote:
> 
> 
> 
> 2017-07-22 0:23 GMT+02:00 Alan W. Irwin :
>> I have built CMake-3.9.0 on my Linux (Debian Jessie) platform using
>> the bootstrap method I have always successfully used for other CMake
>> versions (including 3.7.2).
>> 
>> For a complex project (PLplot) which uses swig_add_module and
>> swig_link_libraries to implement our Java binding, I get the following
>> error message at the end of that CMake-3.9.0 output.
>> 
>> -- Configuring done
>> CMake Error: Error required internal CMake variable not set, cmake may
>> not be built correctly.
>> Missing variable is:
>> CMAKE_Java_CREATE_SHARED_MODULE
>> -- Generating done
>> -- Build files have been written to:
>> /home/software/plplot/HEAD/build_dir
>> 
>> I don't get this error message for CMake-3.7.2.
>> 
>> Using find and xargs -0 grep I have looked in both 3.7.2 and 3.9.0
>> source code for any mention of CMAKE_Java_CREATE_SHARED_MODULE, and it
>> just does not exist.
>> 
>> By the way, I have tried the following simple project.
>> 
>> cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR)
>> project(test_java NONE)
>> enable_language(Java)
>> message(STATUS "CMAKE_Java_CREATE_SHARED_MODULE = 
>> ${CMAKE_Java_CREATE_SHARED_MODULE}")
> 
> I'm curious with that.
> I do currently use UseJava.cmake module
> https://cmake.org/cmake/help/v3.7/module/UseJava.html
> for building some java bits in a globally C++ project.
> 
> I never tried  enable_language(Java)
> what is the status of Java support as a primary language?
> 
> I tried to find informations about that in the doc and mailing list but 
> didn't find much.
> 
> Could someone please point me to the appropriate place concerning this?
> 
> 
> -- 
> Eric
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

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] How do I specify VTK minimum version?

2017-07-24 Thread David Cole via CMake
You don't have to ask for a specific version. You can just do:

find_package(VTK REQUIRED)

if you don't really care what version is found.

Or if you need >= 7, you can do it like that and then check what
version was actually found, and error out yourself if it is too old.


HTH,
David C.



On Mon, Jul 24, 2017 at 10:52 AM, Victor Lamoine
 wrote:
> Thank you for the answers.
>
> I used this script to fix my problem:
>
> find_package(VTK 7.1.0 QUIET)
> if (NOT VTK_FOUND)
>   find_package(VTK 8.0.0 REQUIRED)
> endif()
> include(${VTK_USE_FILE})
>
> Of course this will only work until there is a VTK 9.x.x version.
>
> --
>
> 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
-- 

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


Re: [cmake-developers] [CMake] CPack install 3rd party shared libraries

2017-07-19 Thread David Cole via cmake-developers
Very nice example. Does CMake have a place to put examples like VTK
does...? If so, where is it? And if not, it would be super useful to
start one somewhere "official."

However, one word of caution on the example. I know it was targeted at
Linux, and perhaps for a very simple case it's proper, but using an
unconditional "local" for everything in a
gp_resolved_file_type_override would not be something you'd want to do
in general, especially on Windows. You would end up with probably on
the order of a hundred (or maybe nowadays even a few hundred) DLLs
from the Windows system directories inside your bundle. Almost
certainly not what you intended.


Cheers,
David C.



On Wed, Jul 19, 2017 at 9:57 AM, Elvis Stansvik
 wrote:
> 2017-07-19 13:42 GMT+02:00 Roman Wüger :
>> The problem with BundleUtilities which Inder is that it doesn't support 
>> generator expressions.
>>
>> Maybe I do something wrong?
>> But I need to specify the path to the executable (generator expression) and 
>> the paths where to look for dependencies. Right?
>
> You don't need to use a generator to fetch the executable path. You
> will know the path, since you installed the executable with
> install(..) :) I think most people essentially hardcode the executable
> path in their call to fixup_bundle(..).
>
> If you really want to, I think there is a way to use generator
> expressions, and that is to put the fixup_bundle(..) call in a
> separate file (say InstallStuff.cmake.in), and then process that file
> with file(GENERATE OUTPUT ...) [1] to produce InstallStuff.cmake with
> generator expressions evaluated and then use install(SCRIPT
> InstallStuff.cmake). But that's much too complicated IMHO, and I would
> avoid it.
>
> I made a minimal example that links against zlib and also the Boost
> library you mentioned:
>
> cmake_minimum_required(VERSION 2.8)
>
> project(bundletest)
>
> find_package(ZLIB REQUIRED)
> find_package(Boost REQUIRED COMPONENTS filesystem)
>
> add_executable(bundletest main.cpp)
>
> target_include_directories(bundletest PRIVATE ${ZLIB_INCLUDE_DIRS}
> ${Boost_INCLUDE_DIRS})
>
> target_link_libraries(bundletest ${ZLIB_LIBRARIES} ${Boost_LIBRARIES})
>
> install(TARGETS bundletest
> RUNTIME DESTINATION "bin"
> )
>
> install(CODE "
> function(gp_resolved_file_type_override resolved_file type_var)
>set(\${type_var} local PARENT_SCOPE)
> endfunction()
> include(BundleUtilities)
> fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/bundletest\" \"\" \"\")
> " COMPONENT Runtime)
>
> main.cpp:
>
> #include 
> #include 
> #include 
>
> using namespace boost::filesystem;
>
> int main (int argc, char *argv[]) {
> // Pretend we're using zlib and Boost
> deflateInit(0, 0);
> std::cout << file_size(argv[1]) << std::endl;
> return 0;
> }
>
> The overriding of the gp_resolved_file_type_override was necessary, to
> make it treat all libraries as local (otherwise it skips "system"
> libraries). See the docs for GetPrerequisites.
>
> Building/installing this with
>
> mkdir build
> cd build
> cmake -DCMAKE_INSTALL_PREFIX=~/bundletest_install ..
> make install
>
> produces:
>
> /home/estan/bundletest_install
> /home/estan/bundletest_install/bin
> /home/estan/bundletest_install/bin/bundletest
> /home/estan/bundletest_install/bin/libm.so.6
> /home/estan/bundletest_install/bin/libstdc++.so.6
> /home/estan/bundletest_install/bin/libc.so.6
> /home/estan/bundletest_install/bin/libz.so.1
> /home/estan/bundletest_install/bin/libpthread.so.0
> /home/estan/bundletest_install/bin/libboost_system.so.1.58.0
> /home/estan/bundletest_install/bin/libgcc_s.so.1
> /home/estan/bundletest_install/bin/libboost_filesystem.so.1.58.0
>
> I did the build on Ubuntu, and tested that it also runs in a clean
> Fedora 24 Docker container.
>
> Hope that helps some.
>
> Elvis
>
> [1] https://cmake.org/cmake/help/v3.9/command/file.html
>
>>
>> Please, could you give me a hint?
>>
>> Regards
>> Roman
>>
>>> Am 19.07.2017 um 12:40 schrieb Elvis Stansvik 
>>> :
>>>
>>> 2017-07-19 10:24 GMT+02:00 Roman Wüger :
 Hello,

 I have a project which depends on a self compiled 3rd party project (boost)
 Boost is here only an example, there are other 3rd party libraries too.

 If I call the "install" command on the target, then it would be packaged.
 But how could I add the shared libraries and especially the links for the 
 shared libraries?

 E.g.:
 libboost_filesystem.so -> libboost_filesystem.so.1.48.0
 libboost_filesystem.so.1.48.0

 Thanks in advance
>>>
>>> I think fixup_bundle() from BundleUtilities is what you want [1].
>>>
>>> We're using it to make our Windows and macOS installs standalone, but
>>> (I think) it should work on Linux as well.
>>>
>>> [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html
>>>

 Best Regards
 Roman
 --

 Powered by 

Re: [CMake] CPack install 3rd party shared libraries

2017-07-19 Thread David Cole via CMake
Very nice example. Does CMake have a place to put examples like VTK
does...? If so, where is it? And if not, it would be super useful to
start one somewhere "official."

However, one word of caution on the example. I know it was targeted at
Linux, and perhaps for a very simple case it's proper, but using an
unconditional "local" for everything in a
gp_resolved_file_type_override would not be something you'd want to do
in general, especially on Windows. You would end up with probably on
the order of a hundred (or maybe nowadays even a few hundred) DLLs
from the Windows system directories inside your bundle. Almost
certainly not what you intended.


Cheers,
David C.



On Wed, Jul 19, 2017 at 9:57 AM, Elvis Stansvik
 wrote:
> 2017-07-19 13:42 GMT+02:00 Roman Wüger :
>> The problem with BundleUtilities which Inder is that it doesn't support 
>> generator expressions.
>>
>> Maybe I do something wrong?
>> But I need to specify the path to the executable (generator expression) and 
>> the paths where to look for dependencies. Right?
>
> You don't need to use a generator to fetch the executable path. You
> will know the path, since you installed the executable with
> install(..) :) I think most people essentially hardcode the executable
> path in their call to fixup_bundle(..).
>
> If you really want to, I think there is a way to use generator
> expressions, and that is to put the fixup_bundle(..) call in a
> separate file (say InstallStuff.cmake.in), and then process that file
> with file(GENERATE OUTPUT ...) [1] to produce InstallStuff.cmake with
> generator expressions evaluated and then use install(SCRIPT
> InstallStuff.cmake). But that's much too complicated IMHO, and I would
> avoid it.
>
> I made a minimal example that links against zlib and also the Boost
> library you mentioned:
>
> cmake_minimum_required(VERSION 2.8)
>
> project(bundletest)
>
> find_package(ZLIB REQUIRED)
> find_package(Boost REQUIRED COMPONENTS filesystem)
>
> add_executable(bundletest main.cpp)
>
> target_include_directories(bundletest PRIVATE ${ZLIB_INCLUDE_DIRS}
> ${Boost_INCLUDE_DIRS})
>
> target_link_libraries(bundletest ${ZLIB_LIBRARIES} ${Boost_LIBRARIES})
>
> install(TARGETS bundletest
> RUNTIME DESTINATION "bin"
> )
>
> install(CODE "
> function(gp_resolved_file_type_override resolved_file type_var)
>set(\${type_var} local PARENT_SCOPE)
> endfunction()
> include(BundleUtilities)
> fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/bundletest\" \"\" \"\")
> " COMPONENT Runtime)
>
> main.cpp:
>
> #include 
> #include 
> #include 
>
> using namespace boost::filesystem;
>
> int main (int argc, char *argv[]) {
> // Pretend we're using zlib and Boost
> deflateInit(0, 0);
> std::cout << file_size(argv[1]) << std::endl;
> return 0;
> }
>
> The overriding of the gp_resolved_file_type_override was necessary, to
> make it treat all libraries as local (otherwise it skips "system"
> libraries). See the docs for GetPrerequisites.
>
> Building/installing this with
>
> mkdir build
> cd build
> cmake -DCMAKE_INSTALL_PREFIX=~/bundletest_install ..
> make install
>
> produces:
>
> /home/estan/bundletest_install
> /home/estan/bundletest_install/bin
> /home/estan/bundletest_install/bin/bundletest
> /home/estan/bundletest_install/bin/libm.so.6
> /home/estan/bundletest_install/bin/libstdc++.so.6
> /home/estan/bundletest_install/bin/libc.so.6
> /home/estan/bundletest_install/bin/libz.so.1
> /home/estan/bundletest_install/bin/libpthread.so.0
> /home/estan/bundletest_install/bin/libboost_system.so.1.58.0
> /home/estan/bundletest_install/bin/libgcc_s.so.1
> /home/estan/bundletest_install/bin/libboost_filesystem.so.1.58.0
>
> I did the build on Ubuntu, and tested that it also runs in a clean
> Fedora 24 Docker container.
>
> Hope that helps some.
>
> Elvis
>
> [1] https://cmake.org/cmake/help/v3.9/command/file.html
>
>>
>> Please, could you give me a hint?
>>
>> Regards
>> Roman
>>
>>> Am 19.07.2017 um 12:40 schrieb Elvis Stansvik 
>>> :
>>>
>>> 2017-07-19 10:24 GMT+02:00 Roman Wüger :
 Hello,

 I have a project which depends on a self compiled 3rd party project (boost)
 Boost is here only an example, there are other 3rd party libraries too.

 If I call the "install" command on the target, then it would be packaged.
 But how could I add the shared libraries and especially the links for the 
 shared libraries?

 E.g.:
 libboost_filesystem.so -> libboost_filesystem.so.1.48.0
 libboost_filesystem.so.1.48.0

 Thanks in advance
>>>
>>> I think fixup_bundle() from BundleUtilities is what you want [1].
>>>
>>> We're using it to make our Windows and macOS installs standalone, but
>>> (I think) it should work on Linux as well.
>>>
>>> [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html
>>>

 Best Regards
 Roman
 --

 Powered by 

Re: [CMake] Debugging custom commands with VS project generator

2017-06-22 Thread David Cole via CMake
When you convert that error code to hex, it's 0xc139, and if you
google that, you see it's an "entry point not found" error code.

Is something in the custom command trying to load a DLL that doesn't
have the expected export? Or perhaps trying to load a DLL of the wrong
architecture?

Or, there's a missing dependency to one of the DLLs you are loading:
https://stackoverflow.com/questions/1649384/c-debugging-exception-c139

I always convert "/" to "\" when modifying the Windows PATH
environment variable. Does "/" always work? (I noticed the forward
slash is being used in the set PATH statements in your build
output...)


HTH,
David C.



On Thu, Jun 22, 2017 at 6:02 AM, James Turner  wrote:
> Hi,
>
> We’re trying to debug a failure of a custom build command, in a Cmake project 
> using Visual Studio 2015. Unfortunately the command works on some Windows 
> setups but not others - clearly there is something install-dependent going 
> on. (It works on my local machine, but not on our Jenkins build server)
>
> Unfortunately, when the command fails, the only output is:
>
> (CustomBuild target) ->
>   C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): 
> error MSB6006: "cmd.exe" exited with code -1073741511. 
> [G:\Jenkins\workspace\FlightGear-Win\build32\src\Main\fgfs.vcxproj]
>
>
> (Full log is visible here: 
> http://build.flightgear.org:8080/job/FlightGear-Win/2867/console )
>
> The relevant Cmake file is here:
>
> 
> https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Main/CMakeLists.txt#l46
>
> Is there any way to get more output from the custom command invocation? Prior 
> to this failure, we had a different issue with missing DLLs, which we fixed 
> by setting PATH via the ‘CMAKE_MSVCIDE_RUN_PATH’ value - this worked fine, so 
> we think the command is running. And the ‘missing DLL’ error was reported + 
> logged clearly in the console, unlike the current failure.
>
> I have tried setting VERBOSE=1 but I expect this doesn’t work with the VS 
> generator? Any other way to get the stdout / stderr of the failing custom 
> command would help.
>
> Kind regards,
> 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
-- 

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

Re: [cmake-developers] Question about ALIAS targets

2017-06-06 Thread David Cole via cmake-developers
>> After my find_package(OtherProj) call, which is a super build which
>> defines lots of imported targets, I want the target to be named gtest
>> to match its library name, but OtherProj has named it googletest.
>
> Why isn't there a standard name? Should upstream provide the imported
> target? Has any effort been made to make upstream provide it? Is the name
> from OtherProj namespaced? Why do you need it to have a particular name? Why
> does OtherProj expose it? Should it expose that target for you to use (it
> seems an internal thing to me)?
>

There is a standard name. "Upstream" in this case is a super build of
many projects, with an imported target for each project named after
the project that means "the main lib (or all the libs) in the
project". Now, for projects that already have "good imported targets"
(Qt, VTK), I don't bother creating imported targets, I allow client
projects to link directly to those imported targets. But for projects
that don't, I create a convenience imported target named after the
project.

In the case of googletest, the project name is named for its GitHub
repo, but there is no library of that name and its install provides no
imported targets. And the "main" library is just gtest. So I create an
imported target named after the project, but in this case, I also want
to create an imported target for each lib. So I do, but that means my
googletest and gtest targets are essentially identical except for
their names. ( ** i.e. aliases of each other, but both imported... **
)

I don't need it to have a particular name, but I want to follow a
chain of naming conventions: naming the project after its repo,
keeping an imported target for each project in my super build named
after the project, and then, where it makes sense, also having
per-library imported targets.

I'm not expecting anybody to do any work on this, or to loosen the
restriction for my convenience... I just wanted to know if there were
a good reason for the error message. Sounds like "nobody needed it
yet, and we were being conservative" is the answer. Which is a good
answer.


Thanks,
David C.
-- 

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] Question about ALIAS targets

2017-06-05 Thread David Cole via cmake-developers
Is there a good reason why this error must be an error?

CMake Error at CMakeLists.txt:23 (add_library):
  add_library cannot create ALIAS target "MyProj::gtest" because target
  "OtherProj::googletest" is IMPORTED.

The line of code is:

add_library(MyProj::gtest ALIAS OtherProj::googletest)

Why is there any restriction on ALIAS targets about what sorts of
targets they may be aliases of?

After my find_package(OtherProj) call, which is a super build which
defines lots of imported targets, I want the target to be named gtest
to match its library name, but OtherProj has named it googletest.

I can brute force this particular one to just be another IMPORTED
target with all the same properties and property values as the
original, but it seems to me this particular case should be allowed
unless there's a fundamental problem I'm not aware of.

Thanks for any explanations


David C.
-- 

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] Force target to always run last?

2017-05-18 Thread David Cole via CMake
Hopefully, somebody else doing something similar to what you're doing
will chime in here.

Seems overly complicated from an outsider's perspective.

If what you say is true ...:
"If 'copy_dlls' happens while 'B' is building, then it's possible the
post-build event run by B that deletes the 'libs' directory also
deletes some files copied by 'copy_dlls'"

...then copy_dlls depends on B, because if it runs before or while B
is running, you have problems. So it has to run after.

Seems like you have some untangling to do.



On Thu, May 18, 2017 at 3:42 PM, Robert Dailey <rcdailey.li...@gmail.com> wrote:
> To be clear, I do have a "package" target per real native target.
> However, if I set up the dependencies like so:
>
> Target 'A' depends on 'copy_dlls'
> Target 'A' depends on target 'B'
> Target 'A_package' depends on 'A'
> Target 'A_package' depends on 'copy_dlls'
>
> Furthermore, the add_custom_command() to delete 'libs' and copy the
> *.so is added to 'A' and 'B' (each for their own 'libs' directory and
> their own *.so output)
>
> Then when I do:
>
> $ ninja A_package
>
> The following items are built in any order (due to parallel builds):
>
> * B
> * A (after B)
> * copy_dlls
>
> If 'copy_dlls' happens while 'B' is building, then it's possible the
> post-build event run by B that deletes the 'libs' directory also
> deletes some files copied by 'copy_dlls', which means those files will
> not get packaged when 'A_package' invokes `ant release` for the APK
> packaging.
>
> I hope that makes the issue a little clearer... sorry for the confusion.
>
> On Thu, May 18, 2017 at 1:22 PM, David Cole <dlrd...@aol.com> wrote:
>> Seems to me the simplest thing to do would be to have copy_dlls depend
>> on nothing, and have package depend on copy_dlls and all the native
>> targets, and then tell your developers to run:
>>
>>   make individualTarget && make package
>>
>> Either that, or introduce a packageIndividualTarget target for each
>> individualTarget.
>>
>> Maybe I just don't understand fully, but why would you ever "make
>> individualTarget" and then expect package to work properly? What if
>> stuff that depends on that individualTarget also needs to rebuild
>> before packaging? Shouldn't you have to do a build all to guarantee
>> that packaging the results works properly?
>>
>>
>>
>>
>>
>>
>> On Thu, May 18, 2017 at 12:16 PM, Robert Dailey
>> <rcdailey.li...@gmail.com> wrote:
>>> So let me go over the problem I'm trying to solve, because it's
>>> possible at this point I'm over-engineering it, but it's hard to fix.
>>>
>>> So my build process is for native shared library targets that
>>> eventually get included in an APK for Android. I'm using the NDK
>>> toolchain to build my native targets. The general flow from nothing to
>>> complete APK is as follows:
>>>
>>> 1. Build all native library targets
>>> 2. Copy native *.so outputs from the CMake build to `libs/armeabi-v7a`
>>> in the android project directory (where the src, res, and other
>>> android directories are located)
>>> 3. Run custom commands that basically invoke 'ant release', and since
>>> I positioned the *.so files under 'libs' they get packaged with the
>>> APK itself.
>>>
>>> This is how I provide support for using CMake to build native, run
>>> java build, and perform APK packaging.
>>>
>>> There's a lot of setup that happens in CMake in order to make sure the
>>> 'ant release' command behaves as expected. I have to handle a few
>>> corner cases:
>>>
>>> * Each new build of the custom target that runs the 'ant release'
>>> command has to only contain the *.so files that were built during that
>>> run
>>> * Various third-party libraries (pre-compiled *.so files) have to also
>>> be copied to libs/armeabi-v7a for only certain android projects,
>>> because we do not want duplicated *.so files across multiple android
>>> libraries (ant release will fail if there are duplicate *.so files
>>> across android project dependencies)
>>>
>>> So given this, my complete pipeline is as follows:
>>>
>>> 1. A `android_clean_libs` custom target is run which iterates all
>>> known native targets with mapped java projects and completely deletes
>>> its 'libs' directory (this is a forced clean prior to building)
>>> 2. A `copy_dlls` target runs next, which copies third party
>>> (precompiled) *.so files to a single common java project, 

Re: [CMake] Force target to always run last?

2017-05-18 Thread David Cole via CMake
Seems to me the simplest thing to do would be to have copy_dlls depend
on nothing, and have package depend on copy_dlls and all the native
targets, and then tell your developers to run:

  make individualTarget && make package

Either that, or introduce a packageIndividualTarget target for each
individualTarget.

Maybe I just don't understand fully, but why would you ever "make
individualTarget" and then expect package to work properly? What if
stuff that depends on that individualTarget also needs to rebuild
before packaging? Shouldn't you have to do a build all to guarantee
that packaging the results works properly?






On Thu, May 18, 2017 at 12:16 PM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> So let me go over the problem I'm trying to solve, because it's
> possible at this point I'm over-engineering it, but it's hard to fix.
>
> So my build process is for native shared library targets that
> eventually get included in an APK for Android. I'm using the NDK
> toolchain to build my native targets. The general flow from nothing to
> complete APK is as follows:
>
> 1. Build all native library targets
> 2. Copy native *.so outputs from the CMake build to `libs/armeabi-v7a`
> in the android project directory (where the src, res, and other
> android directories are located)
> 3. Run custom commands that basically invoke 'ant release', and since
> I positioned the *.so files under 'libs' they get packaged with the
> APK itself.
>
> This is how I provide support for using CMake to build native, run
> java build, and perform APK packaging.
>
> There's a lot of setup that happens in CMake in order to make sure the
> 'ant release' command behaves as expected. I have to handle a few
> corner cases:
>
> * Each new build of the custom target that runs the 'ant release'
> command has to only contain the *.so files that were built during that
> run
> * Various third-party libraries (pre-compiled *.so files) have to also
> be copied to libs/armeabi-v7a for only certain android projects,
> because we do not want duplicated *.so files across multiple android
> libraries (ant release will fail if there are duplicate *.so files
> across android project dependencies)
>
> So given this, my complete pipeline is as follows:
>
> 1. A `android_clean_libs` custom target is run which iterates all
> known native targets with mapped java projects and completely deletes
> its 'libs' directory (this is a forced clean prior to building)
> 2. A `copy_dlls` target runs next, which copies third party
> (precompiled) *.so files to a single common java project, in its
> 'libs/armeabi-v7a' directory.
> 3. Each native target now builds in parallel, as a post-build event it
> copies its output *.so file to its respective libs/armeabi-v7a
> directory for packaging.
> 4. A final 'package' custom target runs which runs 'ant release' on
> the bottom-most android project (that is not a library target by
> itself).
>
> The part I don't like here is step #1. I don't like the clean to
> require keeping track of a global property of a list of directories to
> remove. Ideally, #1 should run as a post-build event during step 3.
> Basically each native target should delete its 'libs' directory prior
> to copying its own *.so target to that directory. However, I can't do
> this because of step #2. Step 2 must happen first, because it's the
> only way I can guarantee that it will execute regardless of which
> target I build (all, or specific target). I make `copy_dlls` a
> dependency of every other target, so it always runs. If I could force
> it to run *last*, then I could simplify step 1.
>
> Sorry if this is too much information or if I've not explained things
> clearly, but I wanted to hash out the details because maybe there is a
> better approach. I'm willing to start from scratch on this if it
> improves the design of the targets.
>
> Thanks again!!
>
>
> On Thu, May 18, 2017 at 10:51 AM, David Cole <dlrd...@aol.com> wrote:
>> I'm sorry, I misunderstood that you wanted it to run last regardless
>> of what target you are building. I was assuming you wanted it to
>> happen when you build the "all" target. I didn't think you wanted to
>> run it after any other *individual* target which you might specify.
>>
>> I don't know of an easy way to do that. You could add a custom command
>> as a post-build command on every single target, but that seems like it
>> wouldn't work for you either, as it would run the command potentially
>> multiple times, with no way to tell whether you're being called last
>> or not.
>>
>> Sorry.
>>
>> Why does this need to run after the build of any individual target?
>> Why not just say there a

Re: [CMake] Force target to always run last?

2017-05-18 Thread David Cole via CMake
I'm sorry, I misunderstood that you wanted it to run last regardless
of what target you are building. I was assuming you wanted it to
happen when you build the "all" target. I didn't think you wanted to
run it after any other *individual* target which you might specify.

I don't know of an easy way to do that. You could add a custom command
as a post-build command on every single target, but that seems like it
wouldn't work for you either, as it would run the command potentially
multiple times, with no way to tell whether you're being called last
or not.

Sorry.

Why does this need to run after the build of any individual target?
Why not just say there are two ways to get it to run: build "all" or
explicitly build it after you build the other individual thing you
want?




On Thu, May 18, 2017 at 10:24 AM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> David,
>
> Thanks for your help. So if I do it as you suggest, this will also
> require I specify `ALL` to add_custom_target(), correct? If I do it
> this way, will it still run even if it isn't a dependency of the
> target I'm building?
>
> Let me set up a simple scenario for my own understanding. Suppose I
> have the following targets:
>
> * A (add_library target)
> * B (add_library target)
> * C (add_custom_target target)
>
> Dependencies:
>
> B depends on A
> C depends on B and A
>
> Normally if I build B, only A and B will build. However, if C was set
> up using `ALL`, will it build C when I build B? So the expected build
> order in this case would be:
>
> 1. A
> 2. B
> 3. C
>
> Thanks in advance.
>
> On Wed, May 17, 2017 at 4:26 PM, David Cole <dlrd...@aol.com> wrote:
>> The way I know how to do this is to add it last at the bottom of the
>> top-level CMakeLists.txt file, and then use add_dependencies to make
>> it depend on all other targets. (Or at least all other "leaf" targets,
>> which further depend on others, ... the sum of which is "all other
>> targets" besides the new "last" target.)
>>
>> So it's not pretty, but it's possible.
>>
>>
>> HTH,
>> David C.
>>
>>
>>
>> On Wed, May 17, 2017 at 11:36 AM, Robert Dailey
>> <rcdailey.li...@gmail.com> wrote:
>>> I have a custom target that must meet the following requirements:
>>>
>>> * It must always run, regardless of what subset of other targets are being 
>>> built
>>> * It must always be the very last thing run. In parallelized builds,
>>> it must wait until all other targets are done building before
>>> starting, so that it is the very last target run, and should not run
>>> in parallel  with others.
>>>
>>> Is this possible? I'm willing to use hackery if needed...
>>>
>>> Running CMake 3.8.0. Thanks!
>>> --
>>>
>>> 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
-- 

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


Re: [CMake] Force target to always run last?

2017-05-17 Thread David Cole via CMake
The way I know how to do this is to add it last at the bottom of the
top-level CMakeLists.txt file, and then use add_dependencies to make
it depend on all other targets. (Or at least all other "leaf" targets,
which further depend on others, ... the sum of which is "all other
targets" besides the new "last" target.)

So it's not pretty, but it's possible.


HTH,
David C.



On Wed, May 17, 2017 at 11:36 AM, Robert Dailey
 wrote:
> I have a custom target that must meet the following requirements:
>
> * It must always run, regardless of what subset of other targets are being 
> built
> * It must always be the very last thing run. In parallelized builds,
> it must wait until all other targets are done building before
> starting, so that it is the very last target run, and should not run
> in parallel  with others.
>
> Is this possible? I'm willing to use hackery if needed...
>
> Running CMake 3.8.0. Thanks!
> --
>
> 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
-- 

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


Re: [CMake] How to get message() to go to stdout when executed from -P?

2017-04-10 Thread David Cole via CMake
>From the Windows command line, you would do it with 2>&1 after the command (2 
>is stderr, and 1 is stdout). You could write your custom command as a batch 
>file or bash script (unfortunately platform dependent) which uses this 
>technique with a single command inside the batch file.


HTH,
David C.


> On Apr 10, 2017, at 6:44 PM, Robert Dailey  wrote:
> 
> When I execute a CMake script as a custom command, message() logs are
> not shown in stdout from that script.
> 
> Is there a way to make it pipe out messages?
> -- 
> 
> 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

-- 

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


Re: [CMake] ExternalProject_Add ... output directy (sln file directory)

2017-03-30 Thread David Cole via CMake
Do give it a BINARY_DIR, but do NOT give it a BUILD_COMMAND. Giving it
an empty BUILD_COMMAND means "do nothing" for the build step and using
"cmake --build ./LibraryBuild" does not work unless cmake is in your
PATH, and with a Visual Studio solution, you also need to specify
"--config Release" or "--config Debug"

Also posted on SO.


HTH,
David C.



On Thu, Mar 30, 2017 at 10:10 AM, Christophe Demez
 wrote:
> Hi,
>
> I'm currently using one CMakeLists.txt file that will execute an external
> CMakeLists.txt (and dependency).
>
> For this I use the ExternalProject_Add command, but I can't find a way to
> specify where the ".sln" file will be generated.
>
> I have also created StackOverflow question here with more information, if
> someone have an idea for a solution ?
>
> http://stackoverflow.com/questions/43117117/cmake-use-externalproject-add-and-specify-the-output-folder
>
> Thanks
> --
>
> 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
-- 

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


Re: [CMake] Running test who have two labels?

2017-03-24 Thread David Cole via CMake
Here's a bash script wrapper you could use with existing ctest. Save
it out to a file named ctest-two-labels.sh and then call it with bash
on Mac or Linux:


label1=$1
label2=$2

if [ -z "$label1" ]; then
echo "script takes two label arguments as input, missing arg 1"
exit 1
fi

if [ -z "$label2" ]; then
echo "script takes two label arguments as input, missing arg 2"
exit 2
fi

tmpfile=./ctest-two-labels-sh-tmp.txt
testlistFile=./ctest-two-labels-sh-testlist.txt
testnumsFile=./ctest-two-labels-sh-testnums.txt

ctest -L "^($label1)$" -N > "$tmpfile"
ctest -L "^($label2)$" -N >> "$tmpfile"

cat "$tmpfile" | grep "  Test #" | sort | uniq -d > "$testlistFile"

cat "$testlistFile" | awk -F "#" '{ print $2; }' | awk -F ":" '{ print
$1; }' > "$testnumsFile"

testnums=$(cat "$testnumsFile" | paste -s -d, -)

#echo Tests with both labels $label1 and $label2:
#cat "$testlistFile"
#
#echo Just the test numbers:
#cat "$testnumsFile"
#
#echo The test numbers, assembled into a ctest -I string to run just
those numbered tests:
#echo $testnums

echo Running command line:
echo ""
echo "  ctest -I \"0,0,0,$testnums\" -N"
echo ""
echo Run it without the -N to actually execute the tests...
echo ""

ctest -I "0,0,0,$testnums" -N



It's a "back of the envelope / proof of concept" script. Polish it up
and make it nice if the approach seems reasonable to you.


HTH,
David C.





On Fri, Mar 24, 2017 at 8:08 AM, Eric Noulard  wrote:
>
>
> 2017-03-24 12:30 GMT+01:00 Nils Gladitz :
>>
>> On 03/24/2017 11:50 AM, Eric Noulard wrote:
>>
>>> Hi there,
>>>
>>> I'm playing with ctest LABELS and I wanted to know whether if it is
>>> possible
>>> to run the set of tests which have 2 labels ?
>>>
>>> I manage to have all tests which have **either** L1 or L2:
>>>
>>> ctest -L "L1|L2"
>>>
>>> but how can I write a proper command line for both L1 and L2 ?
>>>
>>> apparently
>>>
>>> ctest -L "L1" -L "L2"
>>>
>>> only takes into account the last -L argument.
>>>
>>
>> I don't think it is possible currently.
>> To a degree you might be able to work around it by creating additional
>> labels that combine the existing ones e.g. "L1", "L2", "L1-L2".
>
>
> Yes of course.
> I do test name mangling but I was hoping for more "classifying" feature with
> labels and was expecting a simple
> OR and AND operation with labels. This is not the case.
>
>
>>
>>
>> I was pondering trying to implement test filtering based on the condition
>> evaluator CMake uses for if()/while() at some point
>> (cmConditionEvaluator.cxx).
>> e.g. --run-tests-if "L1 IN_LIST TEST_LABELS AND L2 IN_LIST TEST_LABELS"
>
>
> It could have been nice but may be overkill my needs.
> A repetable ANDing -L or -LE will do the job.
>
> That said since test filtering is regex-based I simply rediscovered that
> ANDing or negating regex is not easy.
>
> --
> Eric
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

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


Re: [CMake] Is it possible to run ctest outside build tree?

2017-03-24 Thread David Cole via CMake
If the implementation is "run ctest in this build tree" and it
effectively simply does a "pushd $build_tree", runs, and then "popd",
then I don't see why anybody would object to it.

Although, a script wrapper would be completely trivial, and work with
existing ctest.


D



On Fri, Mar 24, 2017 at 3:11 PM, Eric Noulard <eric.noul...@gmail.com> wrote:
> Hi David,
> Thank you for you for checking the code. Would you think adding such a
> command line option would be acceptable upstream?
>
> Le 24 mars 2017 18:43, "David Cole" <dlrd...@aol.com> a écrit :
>
> This code:
>
> https://github.com/Kitware/CMake/blob/master/Source/ctest.cxx#L139-L157
>
> shows ctest will look for a CTestTestfile.cmake or DartTestfile.txt
> file in the current working directory as soon as it starts. Except in
> the case of processing a "--launch" directive, in which case, it
> dispatches that in the code just above there.
>
> So. I think you have not much choice other than to propose adding a
> new command line argument for such purpose, or wrapping existing ctest
> with your own script or program of some sort.
>
>
> HTH,
> David C.
>
>
>
>
> On Fri, Mar 24, 2017 at 6:04 AM, Eric Noulard <eric.noul...@gmail.com>
> wrote:
>> Is possible to run ctest outside the builld tree and how?
>> typical use is when I have an out of source build I may be in the source
>> tree
>> and want to run tests without manually going to build tree.
>>
>> i.e. I currently do:
>>
>> ninja -C /my/build/tree
>>
>> is there a similar way to do that with ctest (other than creating my own
>> script, shell alias etc...)?
>>
>> --
>> Eric
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>
>
-- 

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

Re: [CMake] Is it possible to run ctest outside build tree?

2017-03-24 Thread David Cole via CMake
This code:

https://github.com/Kitware/CMake/blob/master/Source/ctest.cxx#L139-L157

shows ctest will look for a CTestTestfile.cmake or DartTestfile.txt
file in the current working directory as soon as it starts. Except in
the case of processing a "--launch" directive, in which case, it
dispatches that in the code just above there.

So. I think you have not much choice other than to propose adding a
new command line argument for such purpose, or wrapping existing ctest
with your own script or program of some sort.


HTH,
David C.




On Fri, Mar 24, 2017 at 6:04 AM, Eric Noulard  wrote:
> Is possible to run ctest outside the builld tree and how?
> typical use is when I have an out of source build I may be in the source
> tree
> and want to run tests without manually going to build tree.
>
> i.e. I currently do:
>
> ninja -C /my/build/tree
>
> is there a similar way to do that with ctest (other than creating my own
> script, shell alias etc...)?
>
> --
> Eric
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

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


Re: [cmake-developers] Debugging issues with enable_language(CSHARP)

2017-03-22 Thread David Cole via cmake-developers
Have you looked into
https://github.com/Kitware/CMake/blob/master/Modules/CMakeDetermineCSharpCompiler.cmake
?

Send steps to reproduce the problem you're seeing... Maybe somebody
else here has encountered the same thing and worked through it
already.


HTH,
David C.



On Wed, Mar 22, 2017 at 12:33 PM, Wesley Smith  wrote:
> Hi,
> I'm trying to diagnose why enable_language(CSHARP) isn't working for me in
> the RC candidate. I've built CMake from source and am trying to step through
> the code, but am coming up against the fact that this is an enormous project
> and I don't quite know where to look.
>
> The new C# support is something I want to use on an upcoming project, so I'd
> like to help solve any issues with it
>
> Here's where I'm at:
>
>
> * I'm stepping through cmGlobalGenerator.xx in the EnableLanguage function.
> When the only language is CSHARP, I'm erroring out where it attempts to get
> the definition of CMAKE_SHARP_COMPILER
>
> * In CMakeErrr.log, I see:
> The CSharp compiler identification could not be found in
> "C:/Users/wes/Documents/GitHub/add-in/build_/CMakeFiles/3.8.20170317-g45851/CompilerIdCSharp/CompilerIdCSharp.csproj"
>
> When I compile and run this project by hand, I'm seeing
>
> InfoCompiler
> "INFO:compiler[Microsoft Visual Studio]"
> InfoPlatform
> "INFO:platform[Windows]"
> InfoArchitecture
> "INFO:arch[x64]"
> InfoCompilerVersion
> "INFO:compiler_version[2017]"
>
> printed from this code:
>
> static void Main(string[] args)
> {
> // we have to print the lines to make sure
> // the compiler does not optimize them away ...
> System.Console.WriteLine(InfoCompiler);
> System.Console.WriteLine(InfoPlatform);
> System.Console.WriteLine(InfoArchitecture);
> System.Console.WriteLine(InfoCompilerVersion);
> }
>
>
> It all looks good to me.  What I haven't been able to find is where the
> project is compiled and run from within CMake and the console stdout read in
> order to verify the C# compiler settings.
>
>
> thanks,
> wes
>
>
> --
>
> 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] CMake 3.7.1 gui fails to launch

2017-01-06 Thread David Cole via CMake
Can you use Qt5? CMake 3.7 is typically built using Qt5: perhaps a Qt5
**requirement** has crept in since it's the commonly used one now.


HTH,
David C.



On Fri, Jan 6, 2017 at 10:41 AM,   wrote:
> I'm running Ubuntu 14.04 and I'm trying to get the current version of CMake
> to run.  (The apt-get version is 2.8).
>
> I installed Qt4 (version 4.8.6) with
>
>   $ sudo apt-get install libqt4-core libqt4-dev libqt4-gui qt4-dev-tools
>
> I installed cmake
>
>   $ ./bootstrap & make & sudo make install
>
> all seemed to run without issue.  Running "cmake-gui --version" reported
> version 3.7.1, but running "cmake-gui" failed:
>
> =
> daryl@eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui --version
> cmake version 3.7.1
>
> CMake suite maintained and supported by Kitware (kitware.com/cmake).
> daryl@eve-ldb:~/cmake/cmake-3.7.1$ cmake-gui
> cmake-gui: symbol lookup error: cmake-gui: undefined symbol:
> _ZN9QListData11detach_growEPii
> ==
>
> That looks like a Qt linkage error.  Any suggestions on resolving this?
> --
>
> 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
-- 

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


Re: [CMake] What are the missing features in Ninja that CMake needs?

2016-12-18 Thread David Cole via CMake
This "compare" view on GitHub shows the difference between the
regular/upstream ninja and the Kitware patched ninja:


https://github.com/ninja-build/ninja/compare/master...Kitware:features-for-fortran

The ReadMe explains the high-level view, and says it is gradually
being worked into upstream ninja.

Looks to me like it deals with "implicit dynamically discovered
dependencies" in the Fortran sources. (i.e., you don't have to say in
the build system input what order Fortran files get compiled in, but
the order is important, and CMake analyzes them to figure it out.)

This change probably helps CMake communicate that info to ninja so
things rebuild properly as files get edited.

I can't tell from a quick glance through exactly what the problem
scenarios are, but I bet Brad King can reply with more info --
probably not till January, though. I saw a message from him Friday
signing off until then.


Cheers,
David C.




On Sat, Dec 17, 2016 at 9:24 PM, Daniel Carrera  wrote:
> Hello,
>
> Kitware maintains a separate release of Ninja in order to support Fortran:
>
> https://github.com/Kitware/ninja
>
>
> I kind of want to ask what Kitware changed, but I probably won't understand
> the details. Instead, I was hoping someone could give me a toy example of a
> Fortran program that cannot be compiled without Kitware's changes to Ninja?
>
> Today I tried to compare CMake+Ninja with Meson+Ninja and both were able to
> handle the toy programs that I threw at them. So I haven't found the corner
> of the parameter space that is fixed by Kitware's patches.
>
> Cheers,
> Daniel.
>
> --
>
> 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
-- 

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


Re: [CMake] Prevent ExternalProject from updating git submodules

2016-12-06 Thread David Cole via CMake
If you customize DOWNLOAD_COMMAND, you should also probably customize
UPDATE_COMMAND. If you are just using a fixed snapshot from some repo,
consider simply using a *.tar.gz snapped to that commit rather than
connecting to the repo at all. The GitHub "/archive/" URLs are perfect
for this.

However, if you are still going to use some sort of git command for
DOWNLOAD_COMMAND, just use:

UPDATE_COMMAND ""

to prevent any git commands from running after the download step.

By the way, it's unclear to me: are you just trying to get something
to work for your project, or are you saying there's a bug in CMake
that needs to be dealt with regardless of what you do for your
project. The repo-based ExternalProject stuff assumes online status is
readily available... If that's not true, you shouldn't use the
repo-based ExternalProject stuff and instead use a "download
everything once to a local spot" and then thereafter use the local
stuff.


HTH,
David C.




On Sun, Dec 4, 2016 at 9:47 PM, Timothy Rae <timothy@sbibits.com> wrote:
> I finally got a chance to try David's suggestion out, but unfortunately that
> doesn't work. I think the ExternalProject script is downloading the
> submodules in a separate step rather than via the "git clone --recursive"
> command.
>
> I simply mentioned the recursive clone as a way to reproduce the issue. You
> could also just set a local filesystem path as the GIT_REPOSITORY and
> disable the internet to reproduce:
>
> 1) git clone https://github.com/ericniebler/range-v3.git LOCAL_CLONE_DIR
> 2) Add ExternalProject_Add(range-v3 GIT_REPOSITORY LOCAL_CLONE_DIR) to a
> project
> 3) Disable the internet
> 4) Attempt to build
>
> ** Watch it hang, and you have to ctrl+c to exit **
>
>
> On 25/10/16 22:12, David Cole wrote:
>>
>> Sounds like you should consider customizing the git clone with
>> DOWNLOAD_COMMAND. You can do anything you want as a customization...
>>
>> HTH,
>> David
>>
>>
>> On Oct 24, 2016, at 11:35 PM, Timothy Rae <timothy@sbibits.com
>> <mailto:timothy@sbibits.com>> wrote:
>>
>>> Thanks for the tip, but I'd rather it didn't fetch the documentation
>>> submodule at all, as this unnecessarily slows down the build.
>>>
>>> On Tue, Oct 25, 2016 at 12:29 PM, Hendrik Sattler
>>> <p...@hendrik-sattler.de <mailto:p...@hendrik-sattler.de>> wrote:
>>>
>>> Hi,
>>>
>>> you can tell git where your copy of tree remote url is. This is
>>> site-specific and does not change the repository:
>>> git config remote."$origirl".url "$newurl"
>>>
>>> HS
>>>
>>>
>>> Am 25. Oktober 2016 03:52:12 MESZ, schrieb Tim Rae
>>> <timothy@sbibits.com <mailto:timothy@sbibits.com>>:
>>>
>>> >Hi all,
>>> >
>>> >I'm using ExternalProject_Add to add the popular C++ library
>>> range-v3
>>> >to
>>> >one of our projects. However, since the build server only has local
>>> >intranet access, and therefore can't access the main github
>>> repository,
>>> >
>>> >we have put a clone of that repo on our local gitlab:
>>> >
>>> >ExternalProject_Add(range-v3
>>> > PREFIX ${PREFIX_DIR}
>>> > GIT_REPOSITORY ${LOCAL_GITLAB_URI}
>>> >)
>>> >
>>> >The problem is that range-v3 has a documentation submodule that
>>> points
>>> >to github, so `git clone ${LOCAL_GITLAB_URI} --recursive` would fail
>>> >when github is inaccessible, whereas git clone works fine without
>>> the
>>> >recursive flag.
>>> >
>>> >I found a previous message from Tim Gallagher on the mailing list
>>> >reporting the same problem, but it looks like the issue was never
>>> >addressed upstream.
>>> >
>>> >https://cmake.org/pipermail/cmake/2015-March/060100.html
>>> <https://cmake.org/pipermail/cmake/2015-March/060100.html>
>>> >
>>> >Unfortunately, specifying GIT_SUBMODULES "" will add all
>>> submodules, so
>>> >
>>> >it doesn't appear that variable will help to solve the issue. I
>>> would
>>> >suggest either having a special value like "__NONE__", or having
>>> a new
>>> >boolean variable like INIT_GIT_SUBMODULES; either of wh

Re: [CMake] Determine which files have changed during a CMake run

2016-11-23 Thread David Cole via CMake
Using git like that is actually the perfect way to do it if you just want
to analyze it manually. I've actually done that with other projects source
trees when something seems to appear there even when doing an out of source
build... It's a great way to see what's changed (and how) easily.

You could also write a CMake script that iterates files in the build
directory, and uses IS_NEWER in conjunction with a reference file touched
just prior to running CMake if you need to generate a report like this
frequently for some reason.

HTH,
David C.


On Wednesday, November 23, 2016, Michael Jackson <
mike.jack...@bluequartz.net> wrote:

> Is there a way to determine which files in my build directory have changed
> for a given run of CMake? The use case is that I made what I thought was a
> small change to my configuration using cmake and when I went to build it
> was basically a full recompile. During our cmake run we do use
> configure_file(...) to generate headers and sources some of which basically
> get included in every source file. I am thinking that I have a dependency
> on generating those files when I probably do not have to.
>
> I use Ninja as my build system if that helps. I could always just hack a
> local git repo for the build folder, commit everything, run cmake and see
> what got changed. Anybody have a better idea?
>
> Thanks
>
> --
> Mike Jackson  [mike.jack...@bluequartz.net]
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

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

Re: [CMake] Prevent ExternalProject from updating git submodules

2016-10-25 Thread David Cole via CMake
Sounds like you should consider customizing the git clone with 
DOWNLOAD_COMMAND. You can do anything you want as a customization...

HTH,
David


> On Oct 24, 2016, at 11:35 PM, Timothy Rae  wrote:
> 
> Thanks for the tip, but I'd rather it didn't fetch the documentation 
> submodule at all, as this unnecessarily slows down the build.
> 
>> On Tue, Oct 25, 2016 at 12:29 PM, Hendrik Sattler  
>> wrote:
>> Hi,
>> 
>> you can tell git where your copy of tree remote url is. This is 
>> site-specific and does not change the repository:
>> git config remote."$origirl".url "$newurl"
>> 
>> HS
>> 
>> 
>> Am 25. Oktober 2016 03:52:12 MESZ, schrieb Tim Rae :
>> >Hi all,
>> >
>> >I'm using ExternalProject_Add to add the popular C++ library range-v3
>> >to
>> >one of our projects. However, since the build server only has local
>> >intranet access, and therefore can't access the main github repository,
>> >
>> >we have put a clone of that repo on our local gitlab:
>> >
>> >ExternalProject_Add(range-v3
>> > PREFIX ${PREFIX_DIR}
>> > GIT_REPOSITORY ${LOCAL_GITLAB_URI}
>> >)
>> >
>> >The problem is that range-v3 has a documentation submodule that points
>> >to github, so `git clone ${LOCAL_GITLAB_URI} --recursive` would fail
>> >when github is inaccessible, whereas git clone works fine without the
>> >recursive flag.
>> >
>> >I found a previous message from Tim Gallagher on the mailing list
>> >reporting the same problem, but it looks like the issue was never
>> >addressed upstream.
>> >
>> >https://cmake.org/pipermail/cmake/2015-March/060100.html
>> >
>> >Unfortunately, specifying GIT_SUBMODULES "" will add all submodules, so
>> >
>> >it doesn't appear that variable will help to solve the issue. I would
>> >suggest either having a special value like "__NONE__", or having a new
>> >boolean variable like INIT_GIT_SUBMODULES; either of which can be used
>> >to disable the automatic initialization of submodules entirely.
>> >
>> >You could also change the default to NOT pull in submodules. This would
>> >
>> >be much better IMHO, as the current behavior is unintuitive. Most
>> >developers (e.g. myself until yesterday) don't even know what a
>> >submodule is, and are only familiar with using git clone, as opposed to
>> >
>> >git clone --recursive. Obviously this would be a breaking change
>> >though,
>> >so I understand that you probably don't want to go with this option.
>> >
>> >For now I have "solved" the problem by adding a new commit to our
>> >range-v3 fork removing all git submodules, however this makes it more
>> >difficult to get the upstream changes in, so I highly recommend adding
>> >an option to disable the automatic initialization of git submodules.
>> >
>> >Best regards,
>> >Tim
>> >
>> >--
>> >*This correspondence (including any attachments) is for the intended
>> >recipient(s) only. It may contain confidential or privileged
>> >information or
>> >both. No confidentiality or privilege is waived or lost by any
>> >mis-transmission. If you receive this correspondence by mistake, please
>> >
>> >contact the sender immediately, delete this correspondence (and all
>> >attachments) and destroy any hard copies. You must not use, disclose,
>> >copy,
>> >distribute or rely on any part of this correspondence (including any
>> >attachments) if you are not the intended recipient(s). 本
>> >メッセージに記載および添付されている情報 (以 下、総称して「本情報」といいます。)は、本来の受信者による使用のみを 意
>> >図しています。誤送信等により
>> >本 情報を取得された場合でも、本情報に係る 秘 密、または法律上の秘匿特権が失われるものではありません。本電子メールを 受
>> >取られた方が、本来の受
>> >信者ではない場合には、本情報及びそのコピー すべ てを削除・破棄し、本電子メールが誤って届い た旨を発信者宛てにご通知下さい ま
>> >すようお願いしま
>> >す。本情報の閲覧、発信または本情報に基づく いかなる行 為も明確に禁止されていることをご了承くださ い。*
>> >--
>> >
>> >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
>> 
>> --
>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
>> 
> 
> 
> This correspondence (including any attachments) is for the intended 
> recipient(s) only. It may contain confidential or privileged information or 
> both. No confidentiality or privilege is waived or lost by any 
> mis-transmission. If you receive this correspondence by mistake, please 
> contact the sender immediately, delete this correspondence (and all 
> attachments) and destroy any hard copies. You must not use, disclose, copy, 
> distribute or rely on any part of this 

Re: [CMake] Force copy of files

2016-10-14 Thread David Cole via CMake
"copy" should always overwrite.

"copy_if_different" will conditionally overwrite, only if the contents
of the two files are different.

If "copy" was not overwriting something when it should have been,
please send steps to reproduce the issue, because that would be a bug.


HTH,
David C.



On Fri, Oct 14, 2016 at 1:47 PM, Aaron Boxer  wrote:
> Never mind, figured this one out:
>
> use copy_if_different
>
> On Fri, Oct 14, 2016 at 1:34 PM, Aaron Boxer  wrote:
>>
>> I have the following lines in my cmake file
>>
>>
>> foreach(f ${MyFiles})
>>   add_custom_command(TARGET ${OPENJPEG_PLUGIN_NAME} PRE_BUILD
>>  COMMAND ${CMAKE_COMMAND} -E
>>  copy ${f} $)
>> endforeach()
>>
>> in order to copy MyFiles to MyFolder.
>>
>>
>> If these files already exist, I would like copy to overwrite the old file.
>> Is there a flag to pass to copy to force this to overwrite?
>>
>> Thanks!
>> Aaron
>
>
>
> --
>
> 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
-- 

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


Re: [CMake] Windows Visual Studio 13 with Ninja & CMake

2016-09-22 Thread David Cole via CMake
Does it work if you launch cmake-gui from the command prompt that
works for your "from the command line" scenario?

On Thu, Sep 22, 2016 at 1:58 PM, Michael Jackson
 wrote:
> My combination is Windows 10 (Anniversary Update), Visual Studio 12 2013
> Update 5, Ninja and CMake 3.5/3.6.
>
> I launch CMake-GUI.exe, select my Source and binary directories and then
> "Configure", select "Ninja" as the generator and then I instantly get the
> error that CMake can not find the C/C++ compilers. I do not recall ever
> having this issue. I just recently updated Windows 10 to the latest so I am
> not sure if that caused something to go wrong? I use the "Zipped" version of
> CMake if that makes a difference. I did have to install the "Windows 8.1
> SDK" in order for QtCreator to work correctly.
>
> I can successfully do the following:
> * Configure and generate from the command line for Ninja
> * Use the CMake-Gui to generate a VS 12 2013 solution file without any
> issues.
> * QtCreator 4.1 can use ninja to properly generate its own projects with a
> correctly detected compiler.
>
> Thoughts?
> --
> Michael A. Jackson
> BlueQuartz Software
> --
>
> 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
-- 

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


Re: [CMake] How to codesign .msi from WIX/CPack?

2016-09-07 Thread David Cole via CMake
There may be a hook at the CPack level you can implement, but I'd have to dig 
to figure out what it is and if it even presently exists.

The easy thing to do would be to implement a custom target which does two 
custom commands: the first the same as CPack (the built-in package target) and 
the second, a custom command to sign the generated .msi file.


David

> On Sep 6, 2016, at 7:52 PM, Eric Wing  wrote:
> 
> I'm finally trying the WIX/CPack MSI generator. Pretty nice!
> 
> One thing I need to do is instruct the build process to codesign via
> signtool.exe. I've managed to figure out how to codesign my .exe via a
> POST_BUILD add_custom_command step.
> 
> But now I would like to make sure the .msi that gets generated also
> gets code signed. But I can't figure out how to do it.
> 
> 
> I seem to need at least two things:
> 
> 1) A post-build hook into the PACKAGE target (add_custom_command
> doesn't seem to do anything when I try to refer to this target).
> 
> 2) The name and location of the .msi that CPack/WIX generated so I can
> refer to it with the signtool command.
> 
> 
> Any advice?
> 
> Thanks,
> Eric
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

-- 

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


Re: [CMake] Windows path too long

2016-09-07 Thread David Cole via CMake
I suppose the obvious "use shorter paths and names" is not possible or hard to 
enforce?


David


> On Sep 7, 2016, at 2:55 AM, Robert Bielik  wrote:
> 
> I have a problem with a VS 2015 project, where the build state path becomes 
> too long:
> 
> SeverityCodeDescriptionProjectFileLineSuppression 
> State
> ErrorMSB3491Could not write lines to file 
> "processor_withAVeryVeryLongName.dir\Release\processo.92BD73FC.tlog\processor_withAVeryVeryLongName.lastbuildstate".
>  The specified path, file name, or both are too long. The fully qualified 
> file name must be less than 260 characters, and the directory name must be 
> less than 248 characters.processor_withAVeryVeryLongNameC:\Program 
> Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets312
> 
> The line in Microsoft.CppBuild.targets is:
> 
>  Lines="$(ProjectStateLine);$(ProjectEvaluationFingerprint)"/>
> 
> I've set CMAKE_OBJECT_PATH_MAX to 240, but I don't think it will affect 
> this...
> 
> Ideas ?
> 
> This is with CMake 3.5.2.
> 
> Regards
> /Robert
> 
> -- 
> 
> 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

-- 

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


Re: [CMake] Setup/tear down steps for CTest

2016-08-21 Thread David Cole via CMake
The best thing to do would be to add the feature to ctest, and
contribute to the CMake community.

I, too, use the "run this test first" and "that test last" technique,
and set up DEPENDS property values to ensure ordering when all tests
are run in parallel. However, as you noted, this does not work to run
subsets of tests reliably. For me, I am able to live with the partial
solution because the vast majority of my tests can be run
independently anyhow and we usually do run all the tests, but a setup
/ teardown step for the whole suite would be a welcome addition to
ctest.

Looking forward to your patch... :-)


David C.


On Sat, Aug 20, 2016 at 8:32 PM, Craig Scott  wrote:
> Let's say a project defines a bunch of tests which require setup and tear
> down steps before/after all the tests are run (not each individual test, I'm
> talking here about one setup before all tests are run and one tear down
> after all tests have finished). While this could be done by a script driving
> CTest itself, it is less desirable since different platforms may need
> different driver scripts and this seems like something CTest should be able
> to handle itself (if the setup/tear down steps use parts of the build, that
> only strengthens the case to have them handled by CMake/CTest directly).
>
> It is possible to abuse the DEPENDS test property and define setup and tear
> down "tests" which are not really tests but which perform the necessary
> steps. While this mostly works, it is not ideal and in particular it doesn't
> work with CTest's --rerun-failed option. I'm wondering if there's currently
> a better way of telling CMake/CTest about a setup step which must be run
> before some particular set of test cases and a tear down step after they are
> all done. The tear down step needs to be performed regardless of whether any
> of the real test cases pass or fail.
>
> The motivating case is to start up and shutdown a service which a (subset
> of) test cases need running. That service is expensive to set up and hence
> it isn't feasible to start it up and shut it down for every test case
> individually.
>
> Any ideas?
>
> --
> Craig Scott
> Melbourne, Australia
> http://crascit.com
>
> --
>
> 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
-- 

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


Re: [CMake] howto retrigger check_function_exists

2016-08-18 Thread David Cole via CMake
The code is not meant to be called. The "require += info_size" line is
to keep compiler optimizations from stripping out the info_size string
variable from the final executable.

This code is simply built, and then the resulting binary is scanned
for the string "INFO:size[],key[]" and then the string
analyzed to pull out the size

Does that make sense?


D



On Thu, Aug 18, 2016 at 3:24 PM, J Decker  wrote:
> I don't understand how this works
>
> info_size[1] will return 'N'
> how will it know it has to pass like 14 arguments to get the right
> character?  And even then the character '4' is not the value 4.
>
>
>
> - this is the code generated for check_type_size
>
> #include 
> #include 
> #include 
> #include "time.h"
>
>
> #undef KEY
> #if defined(__i386)
> # define KEY '_','_','i','3','8','6'
> #elif defined(__x86_64)
> # define KEY '_','_','x','8','6','_','6','4'
> #elif defined(__ppc__)
> # define KEY '_','_','p','p','c','_','_'
> #elif defined(__ppc64__)
> # define KEY '_','_','p','p','c','6','4','_','_'
> #endif
>
> #define SIZE (sizeof(time_t))
> char info_size[] =  {'I', 'N', 'F', 'O', ':', 's','i','z','e','[',
>   ('0' + ((SIZE / 1)%10)),
>   ('0' + ((SIZE / 1000)%10)),
>   ('0' + ((SIZE / 100)%10)),
>   ('0' + ((SIZE / 10)%10)),
>   ('0' +  (SIZE% 10)),
>   ']',
> #ifdef KEY
>   ' ','k','e','y','[', KEY, ']',
> #endif
>   '\0'};
>
> #ifdef __CLASSIC_C__
> int main(argc, argv) int argc; char *argv[];
> #else
> int main(int argc, char *argv[])
> #endif
> {
>   int require = 0;
>   require += info_size[argc];
>   (void)argv;
>   return require;
> }
>
>
>
>
>
>
> On Thu, Aug 18, 2016 at 11:50 AM, J Decker  wrote:
>>
>> I was trying to add some libraries for CMAKE_REQUIRED_LIBRARIES to be able
>> to find more symbols, but changing that didn't cause the
>> check_function-0exists to re-run; is there a shorter way to get it to re-run
>> without deleting CMakeCache.txt?
>> I'm not abject to manually editing files; I had tried to remove just the
>> cached variable reference, but that didn't help.
>>
>> Same for check_type_size() I guess
>
>
>
> --
>
> 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
-- 

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


Re: [cmake-developers] [CMake 0015749]: Make the URL option of ExternalProject_Add to accept lists

2016-07-13 Thread David Cole via cmake-developers
Looks like you could also use a list of paths if you express them in
"file://..." form. Local files can also be expressed as URLs.


David C.



On Wed, Jul 13, 2016 at 4:18 AM, Schmertmann, Lars
 wrote:
> Hello there,
>
> I try to continue the work from André.
> With the attached patch it is possible to use a list of URLs
> but it is still limited to a single path.
>
> I think for a mix of pathes/URLs we need to move a lot of code
> from ExternalProject.cmake into ExternalProject-download.cmake.
> Maybe it is good to realize this in a new ticket/commit?
>
> Best regards
> Lars Schmertmann
>
>
> --
>
> 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

[CMake] cmp0065

2016-07-06 Thread David Cole via CMake
Seems like you ought to be able to avoid this warning just by setting
ENABLE_EXPORTS to 0 or 1 ... If you're going to require 3.0, then use 3.0.
If you're going to use 3.5, then add the property to squelch the warning
and get the behavior you want.


D


On Wednesday, July 6, 2016, J Decker  wrote:

>
> M:/tmp/cmake_cmp0065/CMakeLists.txt(1):  cmake_minimum_required(VERSION
> 3.0 )
> M:/tmp/cmake_cmp0065/CMakeLists.txt(2):  project(cmake-test )
> M:/tmp/cmake_cmp0065/CMakeLists.txt(3):  add_executable(myExe main.c )
> M:/tmp/cmake_cmp0065/CMakeLists.txt(4):  target_compile_definitions(myExe
> PRIVATE MY_DEFINITION )
> M:/tmp/cmake_cmp0065/CMakeLists.txt(5):  target_compile_definitions(myExe
> PRIVATE VERSION_STRING="0.8.15" )
> M:/tmp/cmake_cmp0065/CMakeLists.txt(6):  set(project myExe )
>
> -- Configuring done
> CMake Warning (dev) in CMakeLists.txt:
>   Policy CMP0065 is not set: Do not add flags to export symbols from
>   executables without the ENABLE_EXPORTS target property.  Run "cmake
>   --help-policy CMP0065" for policy details.  Use the cmake_policy command
> to
>   set the policy and suppress this warning.
>
>   For compatibility with older versions of CMake, additional flags may be
>   added to export symbols on all executables regardless of thier
>   ENABLE_EXPORTS property.
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> -- Generating done
> -- Build files have been written to: M:/tmp/cmake_cmp0065/build
>
> ---
> you have cmake_minimum_required(VERSION 3.5 ) in your example... setting
> 3.0 instead and adding --trace shows the warning...
>
> -
> then command you said to use is doing exactly the same thing I'm doing to
> the same target property... of course it should generate the same
> result and it does.
>
>
>
-- 

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

Re: [CMake] cmp0065

2016-07-06 Thread David Cole via CMake
Seems like you ought to be able to avoid this warning just by setting
ENABLE_EXPORTS to 0 or 1 ... If you're going to require 3.0, then use 3.0.
If you're going to use 3.5, then add the property to squelch the warning
and get the behavior you want.


D


On Wednesday, July 6, 2016, J Decker  wrote:

>
> M:/tmp/cmake_cmp0065/CMakeLists.txt(1):  cmake_minimum_required(VERSION
> 3.0 )
> M:/tmp/cmake_cmp0065/CMakeLists.txt(2):  project(cmake-test )
> M:/tmp/cmake_cmp0065/CMakeLists.txt(3):  add_executable(myExe main.c )
> M:/tmp/cmake_cmp0065/CMakeLists.txt(4):  target_compile_definitions(myExe
> PRIVATE MY_DEFINITION )
> M:/tmp/cmake_cmp0065/CMakeLists.txt(5):  target_compile_definitions(myExe
> PRIVATE VERSION_STRING="0.8.15" )
> M:/tmp/cmake_cmp0065/CMakeLists.txt(6):  set(project myExe )
>
> -- Configuring done
> CMake Warning (dev) in CMakeLists.txt:
>   Policy CMP0065 is not set: Do not add flags to export symbols from
>   executables without the ENABLE_EXPORTS target property.  Run "cmake
>   --help-policy CMP0065" for policy details.  Use the cmake_policy command
> to
>   set the policy and suppress this warning.
>
>   For compatibility with older versions of CMake, additional flags may be
>   added to export symbols on all executables regardless of thier
>   ENABLE_EXPORTS property.
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> -- Generating done
> -- Build files have been written to: M:/tmp/cmake_cmp0065/build
>
> ---
> you have cmake_minimum_required(VERSION 3.5 ) in your example... setting
> 3.0 instead and adding --trace shows the warning...
>
> -
> then command you said to use is doing exactly the same thing I'm doing to
> the same target property... of course it should generate the same
> result and it does.
>
>
>
-- 

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

Re: [CMake] execute_process, cmd /c and vcvarsall

2016-06-10 Thread David Cole via CMake
The easiest way to do what you want here is to make a standalone
script (*.bat / *.cmd) that runs the commands you want and get it to
work without CMake involvement at all, and then simply use
execute_process to invoke that script.

You can pass arguments to it if you need to communicate information
from CMake to the script, but if you **require** environment for your
command to run, the easiest way to achieve it is to write a script
that sets up the env, and then executes the command, and then restores
the environment (if necessary).

In Windows *.cmd files, it's easy to save/restore the environment by
using "setlocal" and "endlocal".

Why bother with all the escaping and special characters in an
execute_process when you could just write a script and then call it?
It will be much easier on the eyes for people having to read your code
in the future if you make it simpler.


HTH,
David C.




On Fri, Jun 10, 2016 at 6:21 AM, Kristian  wrote:
> After some tries I found maybe a solution for you. In my small example, I
> had these lines, which are working:
>
>
>> set(HELLO1 "C:/Program Files (x86)/Microsoft Visual Studio
>> 14.0/VC/vcvarsall.bat")
>> execute_process(COMMAND ${HELLO1} && msbuild /help WORKING_DIRECTORY
>> "${CMAKE_CURRENT_SOURCE_DIR}")
>
> So for you, it would look like this (I am not very sure about it):
>
> ==
>
>
> execute_process( COMMAND
> $ENV{VS${VS_IDE_VERSION}0COMNTOOLS}../../VC/vcvarsall.bat x86_amd64 &&
> ${CUDA_NVCC_EXECUTABLE}
> ${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu --run
>
>  WORKING_DIRECTORY
> "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/"
>
>  RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out
>
>  OUTPUT_STRIP_TRAILING_WHITESPACE)
>
>
> ==
>
> Anyhow, when I tried several types of your presentation, I got always some
> errors. I do not know, if this is a bug or not, but I will write them down
> here. Maybe some of the others could write something about it.
>
>
> *** First try ***
>
>> set(HELLO1 "C:/Program Files (x86)/Microsoft Visual Studio
>> 14.0/VC/vcvarsall.bat")
>> execute_process(COMMAND cmd /c "call ${HELLO1}" WORKING_DIRECTORY
>> "${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE
>> _nvcc_out)
>> message("${_nvcc_out}")
>
> When I call these lines on a windows machine, I am getting the error
>
>> 'C:/Program' is not recognized as an internal or external command,
>> operable program or batch file.
>
> *** Second try ***
>
> When I change the execute_process to this
>
>> execute_process(COMMAND cmd /c "call \"${HELLO1}\"" WORKING_DIRECTORY
>> "${CMAKE_CURRENT_SOURCE_DIR}" RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE
>> _nvcc_out)
>
> then I am getting this error
>
>> '\"C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/vcvarsall.bat\"'
>> is not recognized as an internal or external command, operable program or
>> batch file.
>
> So now, CMake / Batch recognizes the right path, but somehow there are the
> characters \".
>
> *** Third try ***
>
> I changed the definition of the variable HELLO1 into (because of some hints
> here
> https://superuser.com/questions/279008/how-do-i-escape-spaces-in-command-line-in-windows-without-using-quotation-marks)
>
>> set(HELLO1 "C:/Program^ Files^ (x86)/Microsoft^ Visual^ Studio^
>> 14.0/VC/vcvarsall.bat")
>
> But here, I am also getting the error
>
>> 'C:/Program' is not recognized as an internal or external command,
>> operable program or batch file.
>
> Even, when I double the carets ^^, then the same error occurs
>
>
> 2016-06-09 22:41 GMT+02:00 Adam Rankin :
>>
>> Hello all,
>>
>>
>>
>> I am trying to develop a execute_process command that will first load the
>> env variables set by the appropriate vcvarsall, and then run a compile
>> command. See here for my progress so far:
>>
>>
>>
>> set(cuda_generation_command cmd /c "\"call
>> \"$ENV{VS${VS_IDE_VERSION}0COMNTOOLS}../../VC/vcvarsall.bat\" x86_amd64 &&
>> \"${CUDA_NVCC_EXECUTABLE}\"
>> \"${OpenCV_SOURCE_DIR}/cmake/checks/OpenCVDetectCudaArch.cu\" \"--run\"\"")
>>
>>
>>
>> execute_process( COMMAND ${cuda_generation_command}
>>
>>  WORKING_DIRECTORY
>> "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/"
>>
>>  RESULT_VARIABLE _nvcc_res OUTPUT_VARIABLE _nvcc_out
>>
>>  OUTPUT_STRIP_TRAILING_WHITESPACE)
>>
>>
>>
>> When run at a command prompt, the command works as expected. When called
>> from CMake, the output is:
>>
>> The filename, directory name, or volume label syntax is incorrect.
>>
>>
>>
>> Has anyone ever succeeded with something like this?
>>
>>
>>
>> Cheers,
>>
>> Adam
>>
>>
>> --
>>
>> 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 

Re: [CMake] How to use CMAKE_MFC_FLAG for only one on executables?

2016-06-01 Thread David Cole via CMake
Or just isolate it into its own CMakeLists.txt file in a sub-directory?

On Wed, Jun 1, 2016 at 8:34 AM, Nicholas Braden
 wrote:
> Have you tried unsetting it after adding the executable in question?
> If that doesn't work, is it possible to make the MFX executable be the
> very last executable added in your project?
>
> On Wed, Jun 1, 2016 at 4:50 AM, Zhang Peixuan  
> wrote:
>> Hello All,
>>
>> I want to use CMake to manage my MFC projects, and I added the following
>> code:
>>
>> set( CMAKE_MFC_FLAG 2)
>> add_executable(MFCDemo WIN32
>> ${MFC_RESOURCE_FILES}
>> ${MFC_HEADER_FILES}
>> ${MFC_SOURCE_FILES}
>> )
>> target_compile_definitions(MFCDemo
>> PUBLIC -D_AFXDLL=1
>> PUBLIC -D_UNICODE
>> PUBLIC -DUNICODE
>> )
>>
>> It works.
>> However, my question is that: In addition to the MFC executable, I still
>> have some non-MFC executables,
>> and once CMAKE_MFC_FLAG is set, all the add_executables' property should be
>> "Use MFC in a Shared DLL".
>> In fact, I want only one MFC executable, and make sure all other executables
>> are "Use Standard Windows Library".
>> Is there any way to implement it? It seems CMAKE_MFC_FLAG does not work with
>> set_target_property or other commands.
>>
>> Thanks,
>> Peixuan Zhang
>>
>> --
>>
>> 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
> --
>
> 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
-- 

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


Re: [CMake] how to add custom command/step to ExternalProject_Add ?

2016-04-08 Thread David Cole via CMake
This file has an example use which executes after download and before configure:

https://github.com/Kitware/CMake/blob/master/Tests/ExternalProjectLocal/CMakeLists.txt


HTH,
David C.


> On Apr 8, 2016, at 6:39 PM, jagernico...@legtux.org wrote:
> 
> Hi,
> 
> my question is related to : 
> http://stackoverflow.com/questions/36506300/using-autogen-sh-with-externalproject-add
> 
> I have to use ExternalProject_Add to compile 
> https://github.com/fukuchi/libqrencode as a gitmodule, it requires to run 
> autogen.sh before running configure.
> 
> I don't understand how to use ExternalProject_Add_Step to add a step before 
> CONFIGURE_COMMAND.
> 
>  
> 
> regards,
> 
> Nicolas
> 
>  
> 
>  
> -- 
> 
> 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
-- 

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

Re: [CMake] Two phase install?

2016-03-24 Thread David Cole via CMake
Are you running a dashboard script (ctest -S script) when this
happens? Or calling ctest directly with other arguments?

If you are running a -S script, you can specify the configuration to
build and test in the script itself with the CTEST_CONFIGURATION_TYPE
script variable. Read the docs here on the ctest_build and ctest_test
steps: https://cmake.org/cmake/help/v3.5/manual/ctest.1.html#ctest-build-step

The ctest_build command also takes a "CONFIGURATION" argument
directly, but surprisingly, the ctest_test command does not seem to
have that arg. https://cmake.org/cmake/help/v3.5/command/ctest_build.html
and https://cmake.org/cmake/help/v3.5/command/ctest_test.html

If you're not calling a -S script, I'm not sure how else you can do it
besides passing "-C Release" on the command line...


HTH,
David C.



On Thu, Mar 24, 2016 at 2:09 PM, Scott Aron Bloom  wrote:
>
>
> -Original Message-
> From: Hendrik Sattler [mailto:p...@hendrik-sattler.de]
> Sent: Thursday, March 24, 2016 3:54 AM
> To: Alan W. Irwin; Scott Aron Bloom
> Cc: cmake@cmake.org
> Subject: Re: [CMake] Two phase install?
>
>
>
> Am 24. März 2016 10:14:40 MEZ, schrieb "Alan W. Irwin" 
> :
>>On 2016-03-24 03:59- Scott Aron Bloom wrote:
>>
>>> That method does NOT work with windows...  And since the visual
>>studio project has the external as a single command, (not sure if its
>>calling nmake or the new build cmd) the proeject is not run in
>>parallel.
>>
>>I am pretty sure ExternalProject_Add only works with generators
>>associated with build commands you can run from the command line such
>>as make, nmake, jom, ninja, etc..  So, for MSVC the way you arrange
>>that is avoid all the visual studio generators, and instead use one of
>>"NMake Makefiles", "NMake Makefiles JOM", or "Ninja".
>
> No. Just as with cmake-generated solutions, you can build those on the 
> command line using msbuild or devenv, the one used by cmake depends on the 
> cmake version. You can even use cmake itself to trigger the right build 
> command for those. Parallel building must be enabled by hand when using 
> msbuild. For devenv, the setting from the IDE is used.
>
> HS
> 
>
> The final hurdle Im hitting.  When ctest is run, on windows I get the 
> complaint that the configuration is not set.
>
> Is there any way to set the -C option to ctest?
>
> Scott
> --
>
> 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
-- 

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

Re: [cmake-developers] Patch to only consider build dependencies between files in the source directory

2016-03-20 Thread David Cole via cmake-developers
Brad's point with "/" or null terminator was that the directory name
**must** be the directory itself, or a sub-directory of the one in
question.

i.e.

if it's "my/src"

then it should either be exactly "my/src" or "my/src/someSubDir" , not
"my/srcSiblingDir"




On Fri, Mar 18, 2016 at 11:52 AM, Attila Krasznahorkay
 wrote:
> Hi Brad,
>
>>> +  // If it's an absolute path, check if it starts with the source
>>> +  // direcotory:
>>> +  return ( ( path.find( SourceDir ) != 0 ) &&
>>> +   ( path.find( BinaryDir ) != 0 ) );
>>
>> Please look at using strncmp and a check that the following character
>> is a nul terminator or '/'.  Otherwise an external location with
>> a common prefix may be mistaken for part of the project.
>
> Not sure what scenario you have in mind here. :-/ std::string::find should 
> only return 0 if the source directory path or binary directory path is what 
> the evaluated path begins with. Why should we worry what the path continues 
> with?
>
> I was wondering about possibly using strncmp, but thought that 
> performance-wise std::string::find should be fine as well here.
>
> I'm not at all against changing the code, I just don't understand yet what 
> setup the current code would not handle correctly.
>
>> Also please add documentation in a
>>
>>  Help/variable/CMAKE_DEPENDS_IN_PROJECT_ONLY.rst
>>
>> file and update Help/manual/cmake-variables.7.rst to reference it.
>
> Will do. Was just not sure where to add this documentation.
>
> Cheers,
> Attila
> --
>
> 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] fixup_bundle on Windows : issue with multiple exe applications

2016-03-19 Thread David Cole via CMake
A multiple folder approach will be very difficult.

The basic assumptions are:

- On Windows, the "one executable path" is the destination path to
which to copy all of the DLLs that need to be copied, so they all end
up in the same directory. (You'd have to have multiple copies in
multiple locations, at which point, it probably makes sense to have
each of your exes set up to use a common shared DLL folder instead.)

- On Mac, the "one executable path" is used to fixup libraries to use
"@executable_path" relative references, so it's different for each
different exe path. If two executables depend on the same library, but
are in different places, but the library is only in one place, then
you cannot use an "@executable_path" relative reference to find the
library.

If all your executables are not in the same directory with each other,
then BundleUtilities will probably not make you a happy camper.


HTH,
David C.



On Fri, Mar 4, 2016 at 9:30 AM, Benjamin Ballet <bbal...@ivsweb.com> wrote:
> FYI verifying_app failed with main.exe failed (3.4.3) because toptool
> depends on topdool.dll located only in toptoolfolder. The workaround is to
> include toptoolfolder in libs folder for fixup_bundle(main.exe...)
>
> David your answer was helpful to me. I know it's an expected behavior.
>
> Would a patch handling such multiple folder application been accepted ? I
> may try to work on it, since I either have to work on the workarounds or a
> nice improvment.
>
>
> 2016-03-04 14:15 GMT+01:00 Benjamin Ballet <bbal...@ivsweb.com>:
>>
>> Indeed I was lucky : It worked with 3.3.1 but not anymore with 3.4.3..
>> I've got a strang bug with one .NET dll generated near a tool :
>>
>> CMake Error at C:/Program Files
>> (x86)/CMake/share/cmake-3.4/Modules/GetPrerequisites.cmake:798 (message):
>> 106>C:/Program Files (x86)/Microsoft Visual Studio
>> 12.0/VC/bin/dumpbin.exe
>> 106>failed: 1181
>>
>> I'm digging
>>
>>
>>
>> 2016-03-03 21:02 GMT+01:00 David Cole <dlrd...@aol.com>:
>>>
>>> It was designed originally with the assumption that all the
>>> executables in a bundle are in the same directory. If you violate that
>>> assumption, I don't think you can count on it to do the right thing
>>> 100% of the time.
>>>
>>> If it works for you calling it multiple times with deepest first, then
>>> maybe you can get lucky...
>>>
>>> I would definitely dig into it and understand exactly what it's doing,
>>> though, if you want to make sure it's going to continue working for
>>> your scenario.
>>>
>>>
>>> HTH,
>>> David C.
>>>
>>>
>>> On Thu, Mar 3, 2016 at 1:43 PM, Benjamin Ballet <bbal...@ivsweb.com>
>>> wrote:
>>> > Hello
>>> >
>>> > I'd like to discuss a problem I encountered today with the very useful
>>> > module BundleUtilities
>>> >
>>> > We have an application on Windows with one main exe file in the top
>>> > folder
>>> > and a few other exe in subdirectories, like that :
>>> >
>>> > applicationfolder  \
>>> >   | main.exe
>>> >   | toolsfolder \
>>> > | supertoolfolder \
>>> > |
>>> > supertool.exe
>>> > | toptoolfolder \
>>> >  |
>>> > toptool.exe
>>> >
>>> > But if I simply call
>>> > fixup_bundle("applicationfolder/main.exe" plugins libs)
>>> >
>>> > the verify_app will fails.
>>> >
>>> > Just a reminder that there is no rpath on Windows : dll must be either
>>> > in
>>> > PATH or in the same folder or in the working directory.
>>> >
>>> > We expected fixup_bundle to copy the required dll for main.exe in
>>> > applicationfolder, the required dll for supertool.exe in
>>> > supertoolfolder and
>>> > the required dll for toptool.exe in toptoolfolder, but it acually
>>> > didn't
>>> > copied anything in supertoolfolder and toptoolfolder.
>>> >
>>> > I worked around this issue by calling fixup_bundle multiple time with
>>> > the
>>> > following order : (the deepest exes first)
>>> >
>>> >
>>> &g

Re: [CMake] File names with unbalanced square brackets

2016-03-18 Thread David Cole via CMake
"A single pair of square brackets with ; inside have also long been
used to designate registry [key;value] pairs on Windows."

http://stackoverflow.com/a/36085151/236192


HTH,
David C.


On Fri, Mar 18, 2016 at 8:21 AM, Allen Barnett  wrote:
> Hi Petr: You're right! If I rename "c" to "c]", it treats the whole
> "/home/allen/test/b[;/home/allen/test/c]" as an element of the list. The
> other file names are correctly split apart.
> Thanks,
> Allen
>
> On Fri, Mar 18, 2016 at 3:17 AM, Petr Kmoch  wrote:
>>
>> Hi Allen.
>>
>> I'm not sure whether it's documented, but CMake interprets square brackets
>> as escaping the semi-colon character (which means a semi-colon in square
>> brackets will not work as a list item separator). You will probably have to
>> translate the file names for CMake processing by replacing [ and ] with a
>> different string, and replacing it back just before use outside of CMake.
>>
>> Petr
>>
>> On Thu, Mar 17, 2016 at 5:38 PM, Allen Barnett 
>> wrote:
>>>
>>> I inherited a set of files with somewhat unusual file names. In
>>> particular, there were a couple of files whose names included a single
>>> square bracket character. I processed these files with the file( GLOB ...)
>>> command and then iterated over the resulting list with foreach. However, the
>>> foreach command does not seem to break the resulting list apart correctly.
>>> To make this concrete, I have a directory with files named "a", "b[", and
>>> "c". file( GLOB FILES "*" ) returns the list:
>>>
>>> /home/allen/test/b[;/home/allen/test/c;/home/allen/test/a
>>>
>>> However,
>>>
>>> foreach( FILE ${FILES} )
>>>   message( ${FILE} )
>>> endforeach()
>>>
>>> just prints the same thing. That is, foreach does not split FILES into
>>> separate pieces. If I rename "b[" to "b]" I see the same behavior. If I
>>> rename "b[" to "b[]" (or even "b]["), then foreach successfully splits FILES
>>> into the individual file names.
>>>
>>> I'm using CMake 3.3.2. I see the same thing on linux and windows.
>>>
>>> Thanks,
>>> Allen
>>>
>>> --
>>>
>>> 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
>>
>>
>
>
> --
>
> 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
-- 

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


Re: [cmake-developers] Listing all targets

2016-03-11 Thread David Cole via cmake-developers
Last I did with it is seen here:

https://github.com/dlrdave/CMake/tree/add-targets-to-get-cmake-property?files=1

I abandoned it because of lack-of-time on my part, and the implementation is 
hacked into cmState... And I didn't have time to wade through and figure out 
what was being refactored around it at the time.

Anyone is welcome to take it and run with it...


David

> On Mar 11, 2016, at 3:58 PM, Clifford Yapp <cliffy...@gmail.com> wrote:
> 
>> On Mon, Sep 14, 2015 at 1:47 PM, Stephen Kelly <steve...@gmail.com> wrote:
>> Brad King wrote:
>> 
>>>> On 09/14/2015 11:46 AM, David Cole wrote:
>>>> (1) I see how I can easily move "COMPONENTS" from
>>>> cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty
>>>> because I can access the global generator from cmState as well...
>>> 
>>> Yes.
>> 
>> I assume you're thinking of getting the global generator from the cmake
>> instance?
>> 
>> That's not appropriate. [...]
> 
>> Making the target names available through properties via cmState is also
>> trivial after targets become first-class parts of cmState (cmState::Target
>> like cmState::Directory).
>> 
>> That can happen sooner (it's on my plate), but required refactoring is also
>> on hold until after CMake 3.4.
> 
> 
> Does anyone recall where the "list all targets" feature ended up?  Is
> it still on hold?  (I apologize if I missed any subsequent discussion
> - just now getting back to this...)
> 
> Cheers,
> CY
> -- 
> 
> 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] Best way to show/include CMake files in IDE

2016-03-07 Thread David Cole via CMake
If you include those files in the source list for a library, executable, or 
custom target, they should show up in IDE projects, and they should be ignored 
by Makefile type projects. Have you tried that?


David

> On Mar 7, 2016, at 6:34 PM, Eric Wing  wrote:
> 
> I have a bunch of .cmake support files in my project that I have split
> off from CMakeLists.txt (using INCLUDE to combine them) to separate
> concerns. (Source files, application assets, script files, platform
> settings, codesigning, etc.)
> 
> This works, but they don't show up in IDEs (Visual Studio, Xcode,
> etc). I realized it would be nice to see these files in the IDE and be
> able to edit them there. (I assume the CMake bootstrap will still just
> work.)
> 
> What is the best way to include/show these files in the IDE (and won't
> break the Makefile or other non-IDE generators)?
> 
> Thanks,
> Eric
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

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


Re: [cmake-developers] C# support ready for review

2016-03-07 Thread David Cole via cmake-developers
Seems to me like C# support should work just fine with other generators: ninja, 
nmake, and UNIX Makefiles included. Especially with mono on Linux/Mac.


David

> On Mar 7, 2016, at 2:12 PM, Brad King  wrote:
> 
>> On 02/25/2016 05:51 AM, Stuermer, Michael  SP/HZA-ZSEP wrote:
>> The part that probably needs most additional work is all the
>> C# detection and configuration part in the module scripts.
> 
> In your branch Modules/CMakeDetermineCSharpCompiler.cmake currently
> has a lot of logic and environment checks for this.  It shouldn't
> need to be that complicated.  Anything requiring deep introspection
> of the system (especially the registry) should be something done
> in the C++ generator implementation and provided to CMake platform
> files as a variable.
> 
> For example, the VS generators always provide msbuild:
> 
> https://cmake.org/cmake/help/v3.5/variable/CMAKE_VS_MSBUILD_COMMAND.html
> 
> For the path to the compiler tool, take a look at
> 
> Modules/CompilerId/VS-10.vcxproj.in
> 
> and use of it by Modules/CMakeDetermineCompilerId.cmake.  That all
> runs while detecting the compiler id using a small test project.
> It has a custom command that searches the PATH in the IDE project
> build environment to print out the path to the compiler.  You should
> create one like this for CSharp too.
> 
> We'll also need to define behavior when CSharp is enabled by projects
> under a non-VS generator.  Other generators should reject any such
> attempt with an error message.
> 
> 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
-- 

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] fixup_bundle on Windows : issue with multiple exe applications

2016-03-03 Thread David Cole via CMake
It was designed originally with the assumption that all the
executables in a bundle are in the same directory. If you violate that
assumption, I don't think you can count on it to do the right thing
100% of the time.

If it works for you calling it multiple times with deepest first, then
maybe you can get lucky...

I would definitely dig into it and understand exactly what it's doing,
though, if you want to make sure it's going to continue working for
your scenario.


HTH,
David C.


On Thu, Mar 3, 2016 at 1:43 PM, Benjamin Ballet  wrote:
> Hello
>
> I'd like to discuss a problem I encountered today with the very useful
> module BundleUtilities
>
> We have an application on Windows with one main exe file in the top folder
> and a few other exe in subdirectories, like that :
>
> applicationfolder  \
>   | main.exe
>   | toolsfolder \
> | supertoolfolder \
> |
> supertool.exe
> | toptoolfolder \
>  |
> toptool.exe
>
> But if I simply call
> fixup_bundle("applicationfolder/main.exe" plugins libs)
>
> the verify_app will fails.
>
> Just a reminder that there is no rpath on Windows : dll must be either in
> PATH or in the same folder or in the working directory.
>
> We expected fixup_bundle to copy the required dll for main.exe in
> applicationfolder, the required dll for supertool.exe in supertoolfolder and
> the required dll for toptool.exe in toptoolfolder, but it acually didn't
> copied anything in supertoolfolder and toptoolfolder.
>
> I worked around this issue by calling fixup_bundle multiple time with the
> following order : (the deepest exes first)
>
> fixup_bundle("applicationfolder/toolsfolder/supertoolfolder/supertool.exe"
> plugins libs)
> fixup_bundle("applicationfolder/toolsfolder/toptoolfolder/toptool.exe"
> plugins libs)
> fixup_bundle("applicationfolder/main.exe" plugins libs)
>
>
> --
> Benjamin BALLET
> Ingénieur R
>
> ACTIVISU
> 19, rue Klock - 92110 Clichy
>> Standard Tél :  01 44 69 37 37
>> www.activisu.com
>
> --
>
> 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
-- 

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

Re: [CMake] Visual Studio and ExternalProject_Add

2016-03-02 Thread David Cole via CMake
Newer versions of Visual Studio install a git, too, for their source
control integration features. Which git is CMake using, the one you've
installed or the one Visual Studio installed?



On Wed, Mar 2, 2016 at 12:45 AM, Kevin Brightwell
 wrote:
> I've been having great success with using ExternalProject over the terrible
> git submodules. However, when using Visual Studio, the following error
> happens:
>
>  Performing download step (git clone) for 'catch-lib'
> 2>  Cloning into 'catch-lib'...
> 2>  Note: checking out 'tags/v1.3.4'.
> 2>
> 2>  You are in 'detached HEAD' state. You can look around, make experimental
> 2>  changes and commit them, and you can discard any commits you make in
> this
> 2>  state without impacting any branches by performing another checkout.
> 2>
> 2>  If you want to create a new branch to retain commits you create, you may
> 2>  do so (now or later) by using -b with the checkout command again.
> Example:
> 2>
> 2>git checkout -b 
> 2>
> 2>  HEAD is now at 3b4edd7... Build for v1.3.4
> 2>  fatal: 'submodule' appears to be a git command, but we were not
> 2>  able to execute it. Maybe git-submodule is broken?
> 2>  CMake Error at
> C:/Users/kevin/dev/sol2/vendor/tmp/catch-lib-gitclone.cmake:58 (message):
> 2>Failed to init submodules in:
> 2>'C:/Users/kevin/dev/sol2/vendor/src/catch-lib'
>
> The CMake file is located here:
> https://github.com/Nava2/sol2/blob/cmake-build/CMakeLists.txt
>
> Steps I've verified:
>
> git.exe is on my system PATH
> The submodule URL is valid
> Builds on OSX/Linux
> Reinstalled git (twice)
>
> I'm new to Visual Studio (I work primarily with Linux/OSX), so I'm sure I'm
> missing something along the way.
>
> Thanks,
>
> --
> Kevin Brightwell. BESc., BSc.
> MESc. Candidate 2017
> Western University
>
>
> --
>
> 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
-- 

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


Re: [CMake] ExternalProject_Add with flexible install commands

2016-02-25 Thread David Cole via CMake
Do you need to do it indirectly through a variable like this?

If you just use:
  INSTALL_COMMAND ""

directly in the ExternalProject_Add call, it will work.

If you really need to do it indirectly, there's probably a way, but it
will also probably be more confusing for people reading the code in
the future. Not sure it's worth that trade-off. You could always
"cheat" and execute a no-op command for the install step rather than
"skipping" it. i.e. INSTALL_COMMAND ${CMAKE_COMMAND} -E echo
NoInstallStep ...


HTH,
David C.




On Thu, Feb 25, 2016 at 11:03 AM, Knox, Kent  wrote:
> Hi Petr~
>
> Thanks for your reply.
>
>
> These set statements do not appear to work.  Either the command 'installs'
> the dependency, or an error pops up.
>
>
> set( rocblas_INSTALL_COMMAND INSTALL_COMMAND "" )
> --> this installs the dependency
>
> set( rocblas_INSTALL_COMMAND INSTALL_COMMAND " " )
> --> /bin/sh: 1:  : not found
>
> set( rocblas_INSTALL_COMMAND INSTALL_COMMAND  )
> --> CMake Warning (dev) in CMakeLists.txt
> --> Argument not separated from preceding token by whitespace.
>
> Kent
>
> 
> From: Petr Kmoch 
> Sent: Thursday, February 25, 2016 2:46 AM
> To: Knox, Kent
> Cc: cmake@cmake.org
> Subject: Re: [CMake] ExternalProject_Add with flexible install commands
>
> Hi Kent,
>
> I believe it's not "empty quotes" that disables the install command, it's
> the empty string. So you should not escape the quotes:
>
> ###
>
> # Default behavior is to NOT install library, empty quotes should disable
> install
> set( libxxx_inst_comm INSTALL_COMMAND "" )
>
> # Build the library as an external project
>   ExternalProject_Add( libxxx
> SOURCE_DIR ${PROJECT_SOURCE_DIR}/src
> ${libxxx_inst_comm}
>   )
> ###
>
> Petr
>
>
> --
>
> 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
-- 

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


Re: [CMake] Cannot set FOLDER property to an interface (header-only) target

2015-12-31 Thread David Cole via CMake
I can't think of a reason why we would not whitelist the FOLDER property...
Unless somebody else chimes in with one, perhaps you could submit a
proposed patch to whitelist it?


D


On Wednesday, December 30, 2015, Klaim - Joël Lamotte 
wrote:

> The following CMake script:
>
> cmake_minimum_required(VERSION 3.4)
>
> add_library( mylib INTERFACE )
> set_property( TARGET mylib PROPERTY FOLDER /some/dir )
>
>
> Will trigger this error on configuration:
>
> CMake Error at CMakeLists.txt:4 (set_property):
>   INTERFACE_LIBRARY targets may only have whitelisted properties.  The
>   property "FOLDER" is not allowed.
>
>
> This prevent any interface library to be organized in Visual Studio
> virtual folders.
> Unfortunately it also mean that header-only targets can't be organized.
>
> I have no idea how this should be solved. Should the property just be
> white-listed?
> Or should a better have a another specific library mode for header-only
> targets?
>
> Is there any workaround?
>
> Joël Lamotte
>
>
-- 

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

Re: [CMake] BitDefender and cmakecompilerid.exe ot cmakecxxcompilerid.exe

2015-12-29 Thread David Cole via CMake
If BitDefender is quarantining those files, I would suspect the compiler you 
are using has somehow become virus-infected...

What does BitDefender say if you ask it to analyze your compiler *.exe?

Maybe you should run a full scan of all the drives you are using here...


HTH,
David



> On Dec 29, 2015, at 4:34 AM, Mauro Ziliani  
> wrote:
> 
> Hi all.
> BitDefender puts the files cmakecompilerid.exe and cmakecxxcompilerid.exe in 
> quarantena.
> 
> It find Gen:Variant.Midie.5130
> 
> It's a fake or is it true?
> 
> Mauro
> -- 
> 
> 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
-- 

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


Re: [CMake] Tests with assert and Release build type

2015-12-23 Thread David Cole via CMake
Not only is it possible ... it WILL happen if you use the Microsoft
C++ compiler and try to mix and match Release and Debug compilation
units.

The MS compiler has some very nice memory tracking facilities built
into the Debug runtime libraries, but it is accomplished via different
structs for Debug and Release builds with extra stuff in the Debug
structs.

So allocations from a Debug compilation unit will not be accessed
correctly in a linked-in Release compilation unit when a pointer to it
is passed across the boundary.

You will see access violations and hard crashes happening in builds
from the Microsoft compiler unless you ensure that everything in a
build has matching Debug/Release defines and compiler settings.

It is only safe to mix-n-match if all calls which cross a boundary
between compilation units have NO differences in their struct and
class definitions from an ABI perspective. Since it is difficult to
verify when this is the case (in general) for large C++ projects, it's
best to avoid mixing and matching...


HTH,
David C.



On Wed, Dec 23, 2015 at 8:29 AM, Ruslan Baratov via CMake
 wrote:
> On 22-Dec-15 04:07, Magnus Therning wrote:
>>
>> Ruslan Baratov writes:
>>
>>> On 20-Dec-15 01:31, Magnus Therning wrote:

 Ruslan Baratov writes:

> How about using RelWithDebInfo? See:
> http://stackoverflow.com/a/28124715/2288008

 Hmm, I'm probably missing something but how does that solve the issue
 with some targets requiring NDEBUG to be *undefined* and other targets
 requiring NDEBUG to be defined?
>>>
>>> I don't think that building targets with different NDEBUG values is a
>>> good idea. More correct approach will be to introduce custom macro to
>>> allow checks (i.e. FOO_NDEBUG/FOO_DEBUG).
>>
>> Why not?
>
> It is possible to hit situation when ODR will be violated, e.g. if somebody
> define optional member in structure with "#if defined(NDEBUG)" condition.
> Something like this:
> http://stackoverflow.com/questions/20833226/library-headers-and-define
>
>>
>> /M
>>
>> --
>> Magnus Therning  OpenPGP: 0x927912051716CE39
>> email: mag...@therning.org   jabber: mag...@therning.org
>> twitter: magthe   http://therning.org/magnus
>>
>> We act as though comfort and luxury were the chief requirements of
>> life, when all that we need to make us happy is something to be
>> enthusiastic about.
>>   -- Albert Einstein
>
>
> --
>
> 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
-- 

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


Re: [CMake] build order

2015-12-19 Thread David Cole via CMake
Build the second thing as an ExternalProject, too, and use the DEPENDS keyword 
to make it build after the first thing.

Don't try to mix-and-match external projects and non-external projects in the 
same CMake configure... It's just too much work to get things working in a 
reasonable cross-platform way. It's possible, but certainly not easy.


David


> On Dec 18, 2015, at 3:29 PM, Owen Hogarth II  wrote:
> 
> If you download, compile and install a cmake project through external project
> 
> How can I make sure that the external project is built before something that 
> depends on that external project?
> -- 
> 
> 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
-- 

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


Re: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd)

2015-12-17 Thread David Cole via cmake-developers
I agree with Brad, the --timeout command line parameter should only
set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test
TIMEOUT properties should be left as is for this change.

A **new** --timeout-scale with well defined / documented interactions
with the global variable and the test properties would be the best
approach for introducing changes in behavior. Or a **new**
--ignore-timeout-test-property to simply use the global value
everywhere for some use cases.


D



On Thu, Dec 17, 2015 at 12:53 PM, Ben Boeckel  wrote:
> On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote:
>> On the cmake general list, Brad recently answered my original query on this
>> subject and appears to agree with me that that ctest --timeout
>> option should always have the highest priority, i.e., override any
>> timeout set by the project such as the above TIMEOUT property.
>
> Here's the snippet from Brad's message:
>
>> From the history of that code it looks like --timeout was added with
>> no consideration of its relationship to CTEST_TEST_TIMEOUT.  Some
>> other CTest options in the same scope as CTEST_TEST_TIMEOUT can be
>> overridden by the command line, so I agree that --timeout should
>> override it too.
>
> 
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/54086/focus=54168
>
> which implies that --timeout sets CTEST_TEST_TIMEOUT, but any properties
> would ignore the setting (as they do now).
>
> --Ben
> --
>
> 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] [CMake] How to set _default_ timeout for the ctest command? (fwd)

2015-12-17 Thread David Cole via cmake-developers
The principle "most local setting wins" should be followed.

If a script is called without --timeout cmd line param, CTEST_TEST_TIMEOUT 
applies, if set. Otherwise default timeout value.

If a script is called with --timeout cmd line param, then that **is** the 
timeout value, and CTEST_TEST_TIMEOUT should be ignored.

In either case, test property TIMEOUT should win/override to preserve the 
backwards compatibility for the use cases which currently depend on that.
 
Good scripts will wrap their setting of CTEST_TEST_TIMEOUT with an "if(NOT 
DEFINED" anyhow... Same with good projects.


David

> On Dec 17, 2015, at 2:42 PM, Ben Boeckel <ben.boec...@kitware.com> wrote:
> 
>> On Thu, Dec 17, 2015 at 13:54:08 -0500, David Cole wrote:
>> I agree with Brad, the --timeout command line parameter should only
>> set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test
>> TIMEOUT properties should be left as is for this change.
> 
> This behavior also makes sense to me. However, what about script mode
> which sets CTEST_TEST_TIMEOUT itself? Is CTEST_TEST_TIMEOUT readonly if
> --timeout is given?
> 
> --Ben
-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd)

2015-12-17 Thread David Cole via cmake-developers
Sounds to me like lapack should conditionally set CTEST_TEST_TIMEOUT only if 
it's not DEFINED already. With such code in the project, callers could define 
it on the command line with -D, or directly in a ctest -S script, and the 
passed in vale would "win" since in this case, the project would NOT set its 
default value.

Pretty standard to do "set only if not set" for variables that callers might 
potentially want to override in a ctest script or in a CMakeLists file.

This works with existing recent versions of cmake and ctest just fine... I 
think ctest has supported -D cmd line params since 3.0 or so.


David

> On Dec 17, 2015, at 6:38 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> 
>> On 2015-12-17 13:54-0500 David Cole wrote:
>> 
>> I agree with Brad, the --timeout command line parameter should only
>> set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test
>> TIMEOUT properties should be left as is for this change.
>> 
>> A **new** --timeout-scale with well defined / documented interactions
>> with the global variable and the test properties would be the best
>> approach for introducing changes in behavior. Or a **new**
>> --ignore-timeout-test-property to simply use the global value
>> everywhere for some use cases.
> 
> This seems like a reasonable approach to me to get these timeout issues
> addressed.
> 
> However, to be clear, here are the consequences for a project like
> lapack where some extrordinary but legitimate timing variations can occur.
> 
> 1. The current advice to such projects would be to rigourously avoid setting 
> either
> CTEST_TEST_TIMEOUT or individual test timeout properties since the user 
> currently
> has no control over those (which illustrates why addressing the above
> issues is important).
> 
> 2. Once the --timeout fix that allows it to override
> CTEST_TEST_TIMEOUT set by the project has become part of a release,
> AND when that version of cmake is the minimum allowed by the project,
> then it will be safe for the project to start using CTEST_TEST_TIMEOUT
> since that value can now be overridden by the user with the --timeout
> option. But the project should still rigourously avoid using
> individual timeout properties until the conditions listed in 3. are
> true.
> 
> 3. Once the implementation of the proposed new --timeout-scale option
> has been implemented and become part of a release, AND when that
> version of cmake is the minimum allowed by the project, then it will
> be safe for such projects to set both CTEST_TEST_TIMEOUT and
> individual timeout properties since the user now has full control
> over all such project timeouts.
> 
> Alan
> __
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
> 
> Linux-powered Science
> __
-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] [CMake] How to set _default_ timeout for the ctest command? (fwd)

2015-12-15 Thread David Cole via cmake-developers
Thanks, Ben. That was gonna be my 2 cents, too:

If I set a test property to have a 1, 5 or 10 second timeout, then I
want the test to timeout if it takes any longer than that. I do this
on tests which must execute quickly even in a loaded CPU scenario. I
would not want the global timeout to take precedence in this case and
have my performance critical test taking much longer than it's
supposed to, and then pass anyway with no timeout indication.

More use cases to consider.

Although I do agree, a command line specified option should take
precedence over the global variable/property.

(Just like the test's timeout property should take precedence over the
global too: it's more local in scope, and should be preferred unless
there's a **new** mechanism introduced to change the existing
behavior.)


D




On Tue, Dec 15, 2015 at 11:20 AM, Ben Boeckel  wrote:
> On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote:
>> On the cmake general list, Brad recently answered my original query on this
>> subject and appears to agree with me that that ctest --timeout
>> option should always have the highest priority, i.e., override any
>> timeout set by the project such as the above TIMEOUT property.  If the
>> consensus continues to be that is the desired behaviour it appears
>> some CMake/CTest code changes will be necessary to change to that
>> behaviour.
>
> Hmm. I don't know. Some tests have timeouts set because they either *do*
> take that long or *shouldn't* take as long as the timeout (e.g., those
> that might deadlock).
>
> I think, instead, that --min-timeout and --max-timeout options might be
> better which allow you to say "this machine is slow; tests may take
> longer (max(property, option))" or "this machine is fast, clamp down the
> timeout (min(property, option))". Alternatively, a --timeout-scale
> option to multiply all timeouts in properties might be better.
>
> --Ben
> --
>
> 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] Problem when using variable_watch with Visual Studio generator in 3.4.1

2015-12-10 Thread David Cole via CMake
I've got a Debug build of current 'master' on Windows, and the problem is
also evident with my build:


C:\dev\dcole\tmp\variable_watch_problem\b1> "C:\dev\repos\My Tests\cmake
Win32-ninja-cl12-Debug\bin\
cmake.exe" -G Ninja ..
-- The CXX compiler identification is MSVC 18.0.31101.0
-- Check for working CXX compiler using: Ninja
-- Check for working CXX compiler using: Ninja -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at N:/repos/cmake/Modules/FindPythonInterp.cmake:161 (include):
  include could not find load file:


÷░♣A/Fin
dPackageHandleStandardArgs.cmake
Call Stack (most recent call first):
  CMakeLists.txt:11 (find_package)


CMake Error at N:/repos/cmake/Modules/FindPythonInterp.cmake:162
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
:
  Unknown CMake command "FIND_PACKAGE_HANDLE_STANDARD_ARGS".
Call Stack (most recent call first):
  CMakeLists.txt:11 (find_package)


-- Configuring incomplete, errors occurred!
See also
"C:/dev/dcole/tmp/variable_watch_problem/b1/CMakeFiles/CMakeOutput.log".


On Thu, Dec 10, 2015 at 7:26 AM, Yves Frederix <
yves.frederix+cm...@gmail.com> wrote:

> After commenting out the call there is no error output:
>
>   -- The CXX compiler identification is MSVC 17.0.61030.0
>   -- Check for working CXX compiler using: Visual Studio 11 2012 Win64
>   -- Check for working CXX compiler using: Visual Studio 11 2012 Win64 --
> works
>   -- Detecting CXX compiler ABI info
>   -- Detecting CXX compiler ABI info - done
>   -- Detecting CXX compile features
>   -- Detecting CXX compile features - done
>   -- Found PythonInterp: C:/Python27/python.exe (found version "2.7.10")
>   -- Configuring done
>   -- Generating done
>
>
> Yves
>
> On Thu, Dec 10, 2015 at 12:58 PM, David Cole <dlrd...@aol.com> wrote:
>
>> Out of curiosity, what output do you get (with 3.4.1) when you comment
>> out your call to variable_watch? Do you still get error output, but without
>> strange symbols in it? Or is there no error output in that case?
>>
>>
>> On Thursday, December 10, 2015, Yves Frederix <
>> yves.frederix+cm...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am experiencing problems during the CMake configure step when using
>>> the function variable_watch. Consider the following minimal CMakeLists
>>> file:
>>>
>>>   cmake_minimum_required(VERSION 3.4)
>>>   project(test CXX)
>>>
>>>   function(myhook _variable _access _value _current_list_file _stack)
>>> if("${_value}" STREQUAL "")
>>>   # Do nothing
>>> endif()
>>>   endfunction()
>>>
>>>   variable_watch(CMAKE_CURRENT_LIST_DIR myhook)
>>>   find_package(PythonInterp REQUIRED)
>>>
>>>
>>> When configuring on Windows using CMake 3.4.1 with the Visual Studio
>>> generator (I tried both VS2012 and VS2015), the process fails with an
>>> error message (notice the strange symbols at the beginning of the line
>>> mentioning FindPackageMessage.cmake):
>>>
>>>   -- Detecting CXX compile features - done
>>> CMake Error at
>>> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:142
>>> (include):
>>>   include could not find load file:
>>>
>>> L☺
>>> /Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageMessage.cmake
>>> Call Stack (most recent call first):
>>>   C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:161
>>> (include)
>>>   CMakeLists.txt:12 (find_package)
>>>
>>>
>>>   CMake Error at
>>>
>>> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:379
>>> (FIND_PACKAGE_MESSAGE):
>>>   Unknown CMake command "FIND_PACKAGE_MESSAGE".
>>>   Call Stack (most recent call first):
>>>
>>> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:162
>>> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>>> CMakeLists.txt:12 (find_package)
>>>
>>>
>>> I did some more testing, and the configuration step is successful when:
>>> - using CMake 2.8.12 or 3.4.0
>>> - using 3.4.1 (or older versions) on osx (I did not try linux)
>>> - removing the 'CXX' in the project call or removing the project call
>>> entirely
>>> - removing the check for _value inside the function
>>>
&g

Re: [CMake] Problem when using variable_watch with Visual Studio generator in 3.4.1

2015-12-10 Thread David Cole via CMake
Out of curiosity, what output do you get (with 3.4.1) when you comment out
your call to variable_watch? Do you still get error output, but without
strange symbols in it? Or is there no error output in that case?


On Thursday, December 10, 2015, Yves Frederix 
wrote:

> Hi all,
>
> I am experiencing problems during the CMake configure step when using
> the function variable_watch. Consider the following minimal CMakeLists
> file:
>
>   cmake_minimum_required(VERSION 3.4)
>   project(test CXX)
>
>   function(myhook _variable _access _value _current_list_file _stack)
> if("${_value}" STREQUAL "")
>   # Do nothing
> endif()
>   endfunction()
>
>   variable_watch(CMAKE_CURRENT_LIST_DIR myhook)
>   find_package(PythonInterp REQUIRED)
>
>
> When configuring on Windows using CMake 3.4.1 with the Visual Studio
> generator (I tried both VS2012 and VS2015), the process fails with an
> error message (notice the strange symbols at the beginning of the line
> mentioning FindPackageMessage.cmake):
>
>   -- Detecting CXX compile features - done
> CMake Error at
> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:142
> (include):
>   include could not find load file:
>
> L☺/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageMessage.cmake
> Call Stack (most recent call first):
>   C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:161
> (include)
>   CMakeLists.txt:12 (find_package)
>
>
>   CMake Error at
>
> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:379
> (FIND_PACKAGE_MESSAGE):
>   Unknown CMake command "FIND_PACKAGE_MESSAGE".
>   Call Stack (most recent call first):
> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:162
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
> CMakeLists.txt:12 (find_package)
>
>
> I did some more testing, and the configuration step is successful when:
> - using CMake 2.8.12 or 3.4.0
> - using 3.4.1 (or older versions) on osx (I did not try linux)
> - removing the 'CXX' in the project call or removing the project call
> entirely
> - removing the check for _value inside the function
>
> It seems that for some reason adding the watch (which actually only
> does read-only access), the contents of the CMAKE_CURRENT_LIST_DIR
> variable is messed up somehow. Could I have run into some corner case
> behavior here?
>
> Maybe it is also useful to mention how I ended up in this situation.
> My requirement was to run some custom code as the very last step of
> the configure process. The solution I found was based on using
> variable_watch (see
>
> http://stackoverflow.com/questions/15760580/execute-command-or-macro-in-cmake-as-last-step-before-configure-step-finishes#15824843
> ),
> but apparently this is not a very robust solution. Are there possibly
> better ways of accomplishing the same thing?
>
> Thanks!
>
> Regards,
> Yves
> --
>
> 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
-- 

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

Re: [CMake] Copying directories as post build events without losing parent directory

2015-12-07 Thread David Cole via CMake
$ cmake -E copy_directory foo bar/foo

?


On Mon, Dec 7, 2015 at 4:53 PM, Robert Dailey  wrote:
> I have a custom target which runs a command similar to this:
>
> $ cmake -E copy_directory foo bar
>
> The problem is that the contents of "foo" are copied inside of "bar",
> instead of it creating a directory "bar/foo" and putting the contents
> in there.
>
> Is there a way to make copy_directory behave like this? If not, I
> guess my only option is to create a little CMake script that runs
> file(INSTALL) to copy the directories like I want.
> --
>
> 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
-- 

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


Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

2015-12-05 Thread David Cole via cmake-developers
Yes, that looks like it should work. I'll pull your branch and give it a
try sometime in the coming week.

Thanks,
David

On Friday, December 4, 2015, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote:

> On Fri, Dec 4, 2015 at 11:32 PM, David Cole <dlrd...@aol.com
> <javascript:;>> wrote:
> > Makes sense.
> >
> > Can I inject my own "#include " into
> > the generated stream, or otherwise inject something into it?
>
> You should be able to do:
>
> target_include_directories(your_target
>   PUBLIC public
>   PRIVATE private
>   )
> target_precompile_headers(your_target
>   PUBLIC
> public_header1.h
> public_header2.h
>   PRIVATE
> private_header1.h
> private_header2.h
>   )
>
> Does that answer your question? Do you think this could solve your
> use-case?
>
> > Specifically, for me, I want to include some, but not ALL VTK headers
> > for a VTK-based project.
>
> I don't see a problem for that.
>
> > Thanks for working on this.
>
> You are welcome. :-)
>
> > Let me know if you want me to be a Visual Studio tester for you.
>
> Yes, please. My main working environment is Linux. I appreciate any
> feedback from different platforms.
>
-- 

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] RFC: CMake precompiled header support and custom compiler based implementation

2015-12-04 Thread David Cole via cmake-developers
With Visual Studio, you definitely **need** separate pch for each CONFIG.
Every pch is going to include headers which have Debug/Release differences
in them, and it is not safe to mix and match compiler output from separate
configs together.


D


On Friday, December 4, 2015, Daniel Pfeifer  wrote:

> My working branch is here:
> https://github.com/purpleKarrot/CMake/commits/pch
>
> Feel free to comment, evaluate, contribute.
>
> I am nut fully decided regarding these two questions:
> - Do we want to support different pch per CONFIG? I think no, but I
> might be wrong.
> - Do we want to support different pch per LANGUAGE? I first thought
> yes, but I am no longer certain about that.
>
> On Fri, Dec 4, 2015 at 5:12 AM, Taylor Braun-Jones
> > wrote:
> > Perhaps the Paris Climate talks would be good inspiration for tackling
> > this feature. How many pounds of CO2 are emitted each year due to
> > needless header compilation CPU cycles? :-)
> >
> > On Fri, Oct 30, 2015 at 1:48 AM, James Johnston
> > > wrote:
> >>> -Original Message-
> >>
> >>> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org
> ]
> >>
> >>> On Behalf Of Daniel Pfeifer
> >>
> >>> Sent: Wednesday, October 28, 2015 08:57
> >>
> >>> To: Taylor Braun-Jones
> >>
> >>> Cc: CMake Developers
> >>
> >>> Subject: Re: [cmake-developers] RFC: CMake precompiled header support
> >>
> >>> and custom compiler based implementation
> >>
> >>>
> >>
> >>> On Tue, Oct 27, 2015 at 3:53 AM, Taylor Braun-Jones  >>
> >>> jones.org> wrote:
> >>
> >>> > What's the status of this PCH feature? Does it need testers? More
> >>
> >>> > design input? I'd love to see this feature in a future CMake release.
> >>
> >>> > Willing to help.
> >>
> >>>
> >>
> >>> I haven't worked on it for quite some time as I currently don't have a
> >>
> >> project
> >>
> >>> which needs it.
> >>
> >>> But I agree that we should get it into CMake, even if it does not
> >>
> >>> support
> >>
> >> all
> >>
> >>> generators yet.
> >>
> >>> Support for additional generators can be added successively.
> >>
> >>>
> >>
> >>> I will rebase my branch to master on the weekend, ie port it to
> >>
> >>> cmGeneratorTarget.
> >>
> >>> Then you are free to help with review, testing, and additional
> generators.
> >>
> >>>
> >>
> >>> Which generators are the most important for you?
> >>
> >>
> >>
> >> I'd also love to see some progress on PCH support, though I haven't had
> much
> >> time recently... I'd be quite happy to test however with the below
> compilers
> >> and generators - all of which we would use PCH support with:
> >>
> >>
> >>
> >> Generators:
> >>
> >>
> >>
> >> * Ninja
> >>
> >> * Visual Studio 2008 (eventually 2015)
> >>
> >> * Although we're not currently using it, CMake would be pretty broken
> >> without supporting: Unix Makefiles
> >>
> >>
> >>
> >> Compilers:
> >>
> >>
> >>
> >> * Visual C++ 2008 (eventually 2015): both Ninja and VS generators
> >>
> >> * Embarcadero bcc32 compiler: Ninja
> >>
> >> * GCC: Ninja
> >>
> >>
> >>
> >> Best regards,
> >>
> >>
> >>
> >> James Johnston
> >>
> >>
> >> --
> >>
> >> 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: 

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

2015-12-04 Thread David Cole via cmake-developers
Right, I was talking about the pch-binary.

Why would CMake even need to generate a header file for pre-compiled
headers? Why not just allow the user to say which of his header files
should be the one to use for precompiled headers?

I have a project I work on which is a VS-only non-CMake based project,
where we name the pch input header files as "${libraryName}PCH.h" and
anything we want included in the pch-binary we can just add to that
file.

Personally, I would prefer to have a manually edited file as the input
to precompiled header so I can add whatever I want in there.

What would be in the contents of the generated header? How do you know
how much or how little is reasonable to put in there? Seems like a
per-library / per-project sort of decision.


D



On Fri, Dec 4, 2015 at 12:26 PM, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote:
>> On Friday, December 4, 2015, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote:
>>>
>>> My working branch is here:
>>> https://github.com/purpleKarrot/CMake/commits/pch
>>>
>>> Feel free to comment, evaluate, contribute.
>>>
>>> I am nut fully decided regarding these two questions:
>>> - Do we want to support different pch per CONFIG? I think no, but I
>>> might be wrong.
>>> - Do we want to support different pch per LANGUAGE? I first thought
>>> yes, but I am no longer certain about that.
>
> On Fri, Dec 4, 2015 at 2:42 PM, David Cole <dlrd...@aol.com> wrote:
>> With Visual Studio, you definitely **need** separate pch for each CONFIG.
>> Every pch is going to include headers which have Debug/Release differences
>> in them, and it is not safe to mix and match compiler output from separate
>> configs together.
>
> Maybe we are confusing two things here.
>
> Visual Studio compiles a pch-binary for each configuration. That
> pch-binary is probably incompatible with other configurations.
> In my current implementation, the header file that is used to compile
> the pch-binary is generated by CMake, using information provided by
> the user.
>
> This approach is very powerful, as it supports usage requirements. See
> here for an example:
> You can see here:
> https://github.com/purpleKarrot/CMake/blob/e441eac5b16fd245e6aa014867d43d53c18b6d4d/Tests/PrecompileHeaders/CMakeLists.txt
>
> My question actually boils down to whether CMake should
> (a) generate a header file for each configuration/language, or
> (b) generate a **single** header file which is then precompiled for
> all configurations/languages.
>
> Both approaches are possible, because we can use #ifdef __cplusplus etc.
>
> More importantly: Do we want the user to
> (c) tell CMake about different headers-to-be-precompiled per
> config/language so CMake can write the appropriate #ifdefs into the
> generated file, or
> (d) put #ifdefs into the provided file so that CMake can #include it
> in the generated file without any additional logic?
>
> Again both approaches are technically possible. It is not about what
> we **need**, but what we **want**. And there, I am undecided.
-- 

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] RFC: CMake precompiled header support and custom compiler based implementation

2015-12-04 Thread David Cole via cmake-developers
Makes sense.

Can I inject my own "#include " into
the generated stream, or otherwise inject something into it?

Specifically, for me, I want to include some, but not ALL VTK headers
for a VTK-based project.

Thanks for working on this.

Let me know if you want me to be a Visual Studio tester for you.


D



On Fri, Dec 4, 2015 at 5:28 PM, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote:
> On Fri, Dec 4, 2015 at 9:19 PM, David Cole <dlrd...@aol.com> wrote:
>> Right, I was talking about the pch-binary.
>>
>> Why would CMake even need to generate a header file for pre-compiled
>> headers? Why not just allow the user to say which of his header files
>> should be the one to use for precompiled headers?
>
> Generating a header file is necessary for two reasons:
>
> 1. In GCC, the compiled pch-binary has to be located in the same
> directory as the pch-source header. For out-of-source-builds, we
> certainly do not want to clutter the source directory, so we need a
> header file inside the binary directory. We could create a copy
> (fragile), a symlink (not portable), or a forward-#include
> (preferred).
>
> 2. There can be only one pch per target. See below.
>
>> I have a project I work on which is a VS-only non-CMake based project,
>> where we name the pch input header files as "${libraryName}PCH.h" and
>> anything we want included in the pch-binary we can just add to that
>> file.
>>
>> Personally, I would prefer to have a manually edited file as the input
>> to precompiled header so I can add whatever I want in there.
>
> That is perfectly reasonable. This is also the reason why I think the
> config/language specific differences should **not** be handled by
> CMake, but by the user.
>
>> What would be in the contents of the generated header? How do you know
>> how much or how little is reasonable to put in there? Seems like a
>> per-library / per-project sort of decision.
>
> If you look at the example I referred to, there is a library `foo`
> with a pch `foo.h` as a usage requirement. There is also an interface
> library `bar` with a pch `bar.h` as a usage requirement. Then there is
> an executable `foobar` which links against both `foo` and bar`. So the
> generated pch-source for the `foobar` target will contain:
>
> 
> /* This file is generated by CMake */
> #include 
> #include 
> 
>
> Making sense?
-- 

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] Fwd: Cmake stucks

2015-11-24 Thread David Cole via cmake-developers
What OS? What version of CMake? What version of VTK? Did you download
CMake, and if so, from where? Or did you build CMake yourself?



On Tue, Nov 24, 2015 at 7:27 AM, Constantinus Spanakis
 wrote:
> Hello, i tried to configure VTK using Cmake, but  every time it stucks
> while checking on the signedness of char and it doesn't move forward.
> What could be the problem?
> --
>
> 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] download file, modify, add test from it

2015-11-23 Thread David Cole via CMake
You're welcome.

I see you have ${file}-2.h5m in only one place, though... Is that a
leftover, or is the other reference to -2 just omitted from your example...?


Cheers,
David C.



On Monday, November 23, 2015, Nico Schlömer <nico.schloe...@gmail.com>
wrote:

> Thanks David for your explanations. I've now reached a good solution:
>
> Fetch the data:
> ```
> INCLUDE(ExternalData)
> set(
>   ExternalData_URL_TEMPLATES
>   "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)"
>   )
> foreach(file ${input_files})
>   ExternalData_Expand_Arguments(
> noshTestFetchData
> OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test/data/${file}.e}
> )
> endforeach()
> ExternalData_Add_Target(noshTestFetchData)
> ```
> Define conversion commands:
> ```
> foreach(file ${input_files})
>   LIST(APPEND FILES2 ${file}-2.h5m)
>   add_custom_command(
> DEPENDS ${file}.e
> COMMAND convert ${file}.e ${file}.h5m
> OUTPUT ${file}.h5m
> )
> endforeach()
> ```
> Add a custom target with ALL:
> ```
> add_custom_target(split2 ALL
>   SOURCES ${FILES2}
>   )
> ```
> Adding the output files to the SOURCES makes the target do what's its
> supposed to do.
>
> Cheers,
> Nico
>
> On Sun, Nov 22, 2015 at 11:59 PM David Cole <dlrd...@aol.com
> <javascript:_e(%7B%7D,'cvml','dlrd...@aol.com');>> wrote:
>
>> You don't. You just assume all relevant targets have already been built
>> by the time you run the tests... There's no such thing as a test from
>> an add_test call depending on a target.
>>
>> There **is** a dependency, of course, if you are using one of the build
>> products in your test, but it's assumed that everything is already built at
>> test time.
>>
>> There is not yet a notion of connecting certain tests to certain build
>> targets.
>>
>> So, for example, there is no way to re-run only the tests affected by
>> things which have changed since the last build, because there is no
>> connection between targets and tests.
>>
>> People have artificially created such connections using test labels, and
>> running subsets of tests by label, but there is no official dependency from
>> tests back to targets.
>>
>>
>> D
>>
>>
>>
>> On Sunday, November 22, 2015, Nico Schlömer <nico.schloe...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','nico.schloe...@gmail.com');>> wrote:
>>
>>> Aha, this was a misunderstanding of me then. Thanks!
>>> How do I make a test depend on a target then?
>>>
>>> Cheers,
>>> Nico
>>>
>>>
>>> On Sun, Nov 22, 2015 at 8:58 PM David Cole <dlrd...@aol.com> wrote:
>>>
>>>> The DEPENDS property of a test is meant to ensure test running order in
>>>> the case of parallel testing... It simply ensures that one test runs before
>>>> another. It is not connected to the build system at all. It's different
>>>> than target dependencies.
>>>>
>>>>
>>>> D
>>>>
>>>>
>>>>
>>>> On Sunday, November 22, 2015, David Cole <dlrd...@aol.com> wrote:
>>>>
>>>>> What do you mean by "depend" in this case? All libs and exes should be
>>>>> built during a "make" or "make all" or "make install" ... And all that
>>>>> should be done before any tests get run.
>>>>>
>>>>> Simply typing "ctest" to execute all the tests never does any
>>>>> building. The assumed workflow is that you build stuff first and then run
>>>>> the tests.
>>>>>
>>>>> If you want, you can add a custom target that runs a test, and make
>>>>> that custom target depend on any other targets, but ctest still won't know
>>>>> about it. Only "make custom_test_target" will...
>>>>>
>>>>>
>>>>> D
>>>>>
>>>>>
>>>>>
>>>>> On Sunday, November 22, 2015, Nico Schlömer <nico.schloe...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Thanks for the hints!
>>>>>> I'm almost there now, the only thing missing is to have my test
>>>>>> depend on the custom_target. This
>>>>>> ```
>>>>>> SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert)
>>>>>> ```
>>>>>> doesn't do the trick: The target `convert` isn't executed before
>>>

Re: [CMake] download file, modify, add test from it

2015-11-22 Thread David Cole via CMake
You don't. You just assume all relevant targets have already been built by
the time you run the tests... There's no such thing as a test from
an add_test call depending on a target.

There **is** a dependency, of course, if you are using one of the build
products in your test, but it's assumed that everything is already built at
test time.

There is not yet a notion of connecting certain tests to certain build
targets.

So, for example, there is no way to re-run only the tests affected by
things which have changed since the last build, because there is no
connection between targets and tests.

People have artificially created such connections using test labels, and
running subsets of tests by label, but there is no official dependency from
tests back to targets.


D



On Sunday, November 22, 2015, Nico Schlömer <nico.schloe...@gmail.com>
wrote:

> Aha, this was a misunderstanding of me then. Thanks!
> How do I make a test depend on a target then?
>
> Cheers,
> Nico
>
>
> On Sun, Nov 22, 2015 at 8:58 PM David Cole <dlrd...@aol.com
> <javascript:_e(%7B%7D,'cvml','dlrd...@aol.com');>> wrote:
>
>> The DEPENDS property of a test is meant to ensure test running order in
>> the case of parallel testing... It simply ensures that one test runs before
>> another. It is not connected to the build system at all. It's different
>> than target dependencies.
>>
>>
>> D
>>
>>
>>
>> On Sunday, November 22, 2015, David Cole <dlrd...@aol.com
>> <javascript:_e(%7B%7D,'cvml','dlrd...@aol.com');>> wrote:
>>
>>> What do you mean by "depend" in this case? All libs and exes should be
>>> built during a "make" or "make all" or "make install" ... And all that
>>> should be done before any tests get run.
>>>
>>> Simply typing "ctest" to execute all the tests never does any building.
>>> The assumed workflow is that you build stuff first and then run the tests.
>>>
>>> If you want, you can add a custom target that runs a test, and make that
>>> custom target depend on any other targets, but ctest still won't know about
>>> it. Only "make custom_test_target" will...
>>>
>>>
>>> D
>>>
>>>
>>>
>>> On Sunday, November 22, 2015, Nico Schlömer <nico.schloe...@gmail.com>
>>> wrote:
>>>
>>>> Thanks for the hints!
>>>> I'm almost there now, the only thing missing is to have my test depend
>>>> on the custom_target. This
>>>> ```
>>>> SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert)
>>>> ```
>>>> doesn't do the trick: The target `convert` isn't executed before
>>>> `ctest`.
>>>>
>>>> Any hints?
>>>>
>>>> Cheers,
>>>> Nico
>>>>
>>>>
>>>> On Sun, Nov 22, 2015 at 3:18 AM David Cole <dlrd...@aol.com> wrote:
>>>>
>>>>> Did you try using full path names for the add_custom_command file
>>>>> names?
>>>>>
>>>>> And the NAME/COMMAND form of the add_test command?
>>>>>
>>>>> Also, I've always found custom commands to work best when they're
>>>>> associated with a target. And if it was part of a target you could make 
>>>>> the
>>>>> target depend on the external data target with add_dependencies if
>>>>> necessary.
>>>>>
>>>>>
>>>>> HTH,
>>>>> David C.
>>>>>
>>>>>
>>>>> On Saturday, November 21, 2015, Nico Schlömer <
>>>>> nico.schloe...@gmail.com> wrote:
>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> I would like to create a CMake test that does the following:
>>>>>>  * Download a file from an external resource
>>>>>>  * Do something with the file
>>>>>>  * compile an executable myTest
>>>>>>  * execute myTest outputfile
>>>>>>
>>>>>> Using ExternalData for downloading the file works well, but the
>>>>>> second step (file conversion, in this example cp for simplicity) does not
>>>>>> work:
>>>>>> ```
>>>>>> cmake_minimum_required(VERSION 3.2)
>>>>>>
>>>>>> project(mytest)
>>>>>>
>>>>>> # Download the files
>>>>>> INCLUDE(ExternalData)
>>>>>> set(

Re: [CMake] download file, modify, add test from it

2015-11-22 Thread David Cole via CMake
Use ALL to include your custom target in the default build of all.

https://cmake.org/cmake/help/v3.4/command/add_custom_target.html


D


On Sunday, November 22, 2015, Nico Schlömer <nico.schloe...@gmail.com>
wrote:

> I was under the impression that if I don't explicitly build a target, it
> won't get build. Perhaps I'm wrong here. In any case, this
> ```
> add_custom_target(convert)
> add_dependencies(convert testFetchData)
> add_custom_command(
>   TARGET convert
>   COMMAND cp test.e test.g
>   )
> ```
> never gets executed on `make`, unlike all other targets (e.g., `
> testFetchData`). (Full CMakeLists.txt at [1].) Explicitly calling `make
> convert` works alright.
>
> Any idea why that might be?
>
> Cheers,
> Nico
>
> [1] http://chunk.io/f/729beeab41fb4a7385ceb98b31a2ea0a
>
> On Sun, Nov 22, 2015 at 8:46 PM David Cole <dlrd...@aol.com
> <javascript:_e(%7B%7D,'cvml','dlrd...@aol.com');>> wrote:
>
>> What do you mean by "depend" in this case? All libs and exes should be
>> built during a "make" or "make all" or "make install" ... And all that
>> should be done before any tests get run.
>>
>> Simply typing "ctest" to execute all the tests never does any building.
>> The assumed workflow is that you build stuff first and then run the tests.
>>
>> If you want, you can add a custom target that runs a test, and make that
>> custom target depend on any other targets, but ctest still won't know about
>> it. Only "make custom_test_target" will...
>>
>>
>> D
>>
>>
>>
>> On Sunday, November 22, 2015, Nico Schlömer <nico.schloe...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','nico.schloe...@gmail.com');>> wrote:
>>
>>> Thanks for the hints!
>>> I'm almost there now, the only thing missing is to have my test depend
>>> on the custom_target. This
>>> ```
>>> SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert)
>>> ```
>>> doesn't do the trick: The target `convert` isn't executed before `ctest`.
>>>
>>> Any hints?
>>>
>>> Cheers,
>>> Nico
>>>
>>>
>>> On Sun, Nov 22, 2015 at 3:18 AM David Cole <dlrd...@aol.com> wrote:
>>>
>>>> Did you try using full path names for the add_custom_command file names?
>>>>
>>>> And the NAME/COMMAND form of the add_test command?
>>>>
>>>> Also, I've always found custom commands to work best when they're
>>>> associated with a target. And if it was part of a target you could make the
>>>> target depend on the external data target with add_dependencies if
>>>> necessary.
>>>>
>>>>
>>>> HTH,
>>>> David C.
>>>>
>>>>
>>>> On Saturday, November 21, 2015, Nico Schlömer <nico.schloe...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I would like to create a CMake test that does the following:
>>>>>  * Download a file from an external resource
>>>>>  * Do something with the file
>>>>>  * compile an executable myTest
>>>>>  * execute myTest outputfile
>>>>>
>>>>> Using ExternalData for downloading the file works well, but the second
>>>>> step (file conversion, in this example cp for simplicity) does not work:
>>>>> ```
>>>>> cmake_minimum_required(VERSION 3.2)
>>>>>
>>>>> project(mytest)
>>>>>
>>>>> # Download the files
>>>>> INCLUDE(ExternalData)
>>>>> set(
>>>>>   ExternalData_URL_TEMPLATES
>>>>>   "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)"
>>>>>   )
>>>>> ExternalData_Expand_Arguments(
>>>>>   testFetchData
>>>>>   OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e}
>>>>>   )
>>>>> ExternalData_Add_Target(testFetchData)
>>>>>
>>>>> add_custom_command(
>>>>>   OUTPUT test.g
>>>>>   COMMAND cp test.e test.g
>>>>>   DEPENDS test.e
>>>>>   )
>>>>>
>>>>> ADD_EXECUTABLE("myTest" main.cpp)
>>>>>
>>>>> add_test(myTest test.g)
>>>>> ```
>>>>> I suppose I'm missing something about the dependencies here; after
>>>>> all, the `add_custom_command` has to wait for `testFetchData` to complete.
>>>>> Likewise, `add_test` has to wait for `add_custom_command` to complete.
>>>>>
>>>>> Hints appreciated.
>>>>>
>>>>> Cheers,
>>>>> Nico
>>>>>
>>>>
-- 

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

Re: [CMake] download file, modify, add test from it

2015-11-22 Thread David Cole via CMake
What do you mean by "depend" in this case? All libs and exes should be
built during a "make" or "make all" or "make install" ... And all that
should be done before any tests get run.

Simply typing "ctest" to execute all the tests never does any building. The
assumed workflow is that you build stuff first and then run the tests.

If you want, you can add a custom target that runs a test, and make that
custom target depend on any other targets, but ctest still won't know about
it. Only "make custom_test_target" will...


D



On Sunday, November 22, 2015, Nico Schlömer <nico.schloe...@gmail.com>
wrote:

> Thanks for the hints!
> I'm almost there now, the only thing missing is to have my test depend on
> the custom_target. This
> ```
> SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert)
> ```
> doesn't do the trick: The target `convert` isn't executed before `ctest`.
>
> Any hints?
>
> Cheers,
> Nico
>
>
> On Sun, Nov 22, 2015 at 3:18 AM David Cole <dlrd...@aol.com
> <javascript:_e(%7B%7D,'cvml','dlrd...@aol.com');>> wrote:
>
>> Did you try using full path names for the add_custom_command file names?
>>
>> And the NAME/COMMAND form of the add_test command?
>>
>> Also, I've always found custom commands to work best when they're
>> associated with a target. And if it was part of a target you could make the
>> target depend on the external data target with add_dependencies if
>> necessary.
>>
>>
>> HTH,
>> David C.
>>
>>
>> On Saturday, November 21, 2015, Nico Schlömer <nico.schloe...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','nico.schloe...@gmail.com');>> wrote:
>>
>>> Hi everyone,
>>>
>>> I would like to create a CMake test that does the following:
>>>  * Download a file from an external resource
>>>  * Do something with the file
>>>  * compile an executable myTest
>>>  * execute myTest outputfile
>>>
>>> Using ExternalData for downloading the file works well, but the second
>>> step (file conversion, in this example cp for simplicity) does not work:
>>> ```
>>> cmake_minimum_required(VERSION 3.2)
>>>
>>> project(mytest)
>>>
>>> # Download the files
>>> INCLUDE(ExternalData)
>>> set(
>>>   ExternalData_URL_TEMPLATES
>>>   "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)"
>>>   )
>>> ExternalData_Expand_Arguments(
>>>   testFetchData
>>>   OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e}
>>>   )
>>> ExternalData_Add_Target(testFetchData)
>>>
>>> add_custom_command(
>>>   OUTPUT test.g
>>>   COMMAND cp test.e test.g
>>>   DEPENDS test.e
>>>   )
>>>
>>> ADD_EXECUTABLE("myTest" main.cpp)
>>>
>>> add_test(myTest test.g)
>>> ```
>>> I suppose I'm missing something about the dependencies here; after all,
>>> the `add_custom_command` has to wait for `testFetchData` to complete.
>>> Likewise, `add_test` has to wait for `add_custom_command` to complete.
>>>
>>> Hints appreciated.
>>>
>>> Cheers,
>>> Nico
>>>
>>
-- 

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

Re: [CMake] download file, modify, add test from it

2015-11-22 Thread David Cole via CMake
The DEPENDS property of a test is meant to ensure test running order in the
case of parallel testing... It simply ensures that one test runs before
another. It is not connected to the build system at all. It's different
than target dependencies.


D



On Sunday, November 22, 2015, David Cole <dlrd...@aol.com> wrote:

> What do you mean by "depend" in this case? All libs and exes should be
> built during a "make" or "make all" or "make install" ... And all that
> should be done before any tests get run.
>
> Simply typing "ctest" to execute all the tests never does any building.
> The assumed workflow is that you build stuff first and then run the tests.
>
> If you want, you can add a custom target that runs a test, and make that
> custom target depend on any other targets, but ctest still won't know about
> it. Only "make custom_test_target" will...
>
>
> D
>
>
>
> On Sunday, November 22, 2015, Nico Schlömer <nico.schloe...@gmail.com
> <javascript:_e(%7B%7D,'cvml','nico.schloe...@gmail.com');>> wrote:
>
>> Thanks for the hints!
>> I'm almost there now, the only thing missing is to have my test depend on
>> the custom_target. This
>> ```
>> SET_TESTS_PROPERTIES(testname PROPERTIES DEPENDS convert)
>> ```
>> doesn't do the trick: The target `convert` isn't executed before `ctest`.
>>
>> Any hints?
>>
>> Cheers,
>> Nico
>>
>>
>> On Sun, Nov 22, 2015 at 3:18 AM David Cole <dlrd...@aol.com> wrote:
>>
>>> Did you try using full path names for the add_custom_command file names?
>>>
>>> And the NAME/COMMAND form of the add_test command?
>>>
>>> Also, I've always found custom commands to work best when they're
>>> associated with a target. And if it was part of a target you could make the
>>> target depend on the external data target with add_dependencies if
>>> necessary.
>>>
>>>
>>> HTH,
>>> David C.
>>>
>>>
>>> On Saturday, November 21, 2015, Nico Schlömer <nico.schloe...@gmail.com>
>>> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> I would like to create a CMake test that does the following:
>>>>  * Download a file from an external resource
>>>>  * Do something with the file
>>>>  * compile an executable myTest
>>>>  * execute myTest outputfile
>>>>
>>>> Using ExternalData for downloading the file works well, but the second
>>>> step (file conversion, in this example cp for simplicity) does not work:
>>>> ```
>>>> cmake_minimum_required(VERSION 3.2)
>>>>
>>>> project(mytest)
>>>>
>>>> # Download the files
>>>> INCLUDE(ExternalData)
>>>> set(
>>>>   ExternalData_URL_TEMPLATES
>>>>   "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)"
>>>>   )
>>>> ExternalData_Expand_Arguments(
>>>>   testFetchData
>>>>   OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e}
>>>>   )
>>>> ExternalData_Add_Target(testFetchData)
>>>>
>>>> add_custom_command(
>>>>   OUTPUT test.g
>>>>   COMMAND cp test.e test.g
>>>>   DEPENDS test.e
>>>>   )
>>>>
>>>> ADD_EXECUTABLE("myTest" main.cpp)
>>>>
>>>> add_test(myTest test.g)
>>>> ```
>>>> I suppose I'm missing something about the dependencies here; after all,
>>>> the `add_custom_command` has to wait for `testFetchData` to complete.
>>>> Likewise, `add_test` has to wait for `add_custom_command` to complete.
>>>>
>>>> Hints appreciated.
>>>>
>>>> Cheers,
>>>> Nico
>>>>
>>>
-- 

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

Re: [CMake] download file, modify, add test from it

2015-11-21 Thread David Cole via CMake
Did you try using full path names for the add_custom_command file names?

And the NAME/COMMAND form of the add_test command?

Also, I've always found custom commands to work best when they're
associated with a target. And if it was part of a target you could make the
target depend on the external data target with add_dependencies if
necessary.


HTH,
David C.


On Saturday, November 21, 2015, Nico Schlömer 
wrote:

> Hi everyone,
>
> I would like to create a CMake test that does the following:
>  * Download a file from an external resource
>  * Do something with the file
>  * compile an executable myTest
>  * execute myTest outputfile
>
> Using ExternalData for downloading the file works well, but the second
> step (file conversion, in this example cp for simplicity) does not work:
> ```
> cmake_minimum_required(VERSION 3.2)
>
> project(mytest)
>
> # Download the files
> INCLUDE(ExternalData)
> set(
>   ExternalData_URL_TEMPLATES
>   "https://downloads.sourceforge.net/project/noshdata/%(algo)/%(hash)"
>   )
> ExternalData_Expand_Arguments(
>   testFetchData
>   OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test.e}
>   )
> ExternalData_Add_Target(testFetchData)
>
> add_custom_command(
>   OUTPUT test.g
>   COMMAND cp test.e test.g
>   DEPENDS test.e
>   )
>
> ADD_EXECUTABLE("myTest" main.cpp)
>
> add_test(myTest test.g)
> ```
> I suppose I'm missing something about the dependencies here; after all,
> the `add_custom_command` has to wait for `testFetchData` to complete.
> Likewise, `add_test` has to wait for `add_custom_command` to complete.
>
> Hints appreciated.
>
> Cheers,
> Nico
>
-- 

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

Re: [CMake] Cmake not working for VS13

2015-11-05 Thread David Cole via CMake
What version of Visual Studio do you have installed?


On Thursday, November 5, 2015, Nikita Barawade <
nikita.baraw...@einfochips.com> wrote:

> Hi,
>
>
> New to cmake utility,
>
> I am trying to build sample program given here
> https://cognitivewaves.wordpress.com/cmake-and-visual-studio/ with VS13
> on windows 7.
>
> Getting following error:
>
> CMake Error at CMakeLists.txt:5 (project): No CMAKE_C_COMPILER could be
> found.
>
> CMake Error at CMakeLists.txt:5 (project): No CMAKE_CXX_COMPILER could be
> found.
>
>
> I searched on Internet but not getting required info.
>
>
> Note:
>
> cmake version 3.4.0
>
> using native compiler option to configure.
>
>
>
> Can anyone give some pointers ?
>
>
> CMake and Visual Studio | Cognitive Waves
> 
> cognitivewaves.wordpress.com
> Introduction Visual Studio to CMake Mapping Example Source Structure
> Execute CMake Visual Studio Solution Explorer View Build and Run
>
>
>
> Regards,
> Nikita
>
> *
> eInfochips Business Disclaimer: This e-mail message and all attachments
> transmitted with it are intended solely for the use of the addressee and
> may contain legally privileged and confidential information. If the reader
> of this message is not the intended recipient, or an employee or agent
> responsible for delivering this message to the intended recipient, you are
> hereby notified that any dissemination, distribution, copying, or other use
> of this message or its attachments is strictly prohibited. If you have
> received this message in error, please notify the sender immediately by
> replying to this message and please delete it from your computer. Any views
> expressed in this message are those of the individual sender unless
> otherwise stated. Company has taken enough precautions to prevent the
> spread of viruses. However the company accepts no liability for any damage
> caused by any virus transmitted by this email.
> *
>
>
-- 

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

Re: [CMake] [CDash] CTEST_CUSTOM_WARNING_EXECPTION

2015-11-05 Thread David Cole via CMake
Does your ctest -S script call ctest_read_custom_files
https://cmake.org/cmake/help/v3.4/command/ctest_read_custom_files.html
after ctest_configure?


On Thursday, November 5, 2015, Rashad M  wrote:

> Hello all,
>
> I have CTestCustom.cmake.in file in source tree with the following
> contents
>
>
> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in
>
> during ctest build CTestCustom.cmake file is getting generated inside the
> build tree.
>
> But however the warnings are not filtered out on the dashboard. For
> instance, see the dashboard submission
> http://dash.orfeo-toolbox.org/viewBuildError.php?type=1=206112
>
> and see the exception for vcl_deprecated_header
>
>
> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in#l69
>
> The warning appears on dashobard anyway. Can someone point me in the right
> direction. ?
>
> Thanks in advance.
>
>
> CMake Version:
> 2.8.12.2
>
> CDash Version:
> 2.2.3
>
> uname -a
> Linux ubuntu
>
>  3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64
> x86_64 x86_64 GNU/Linux
> --
> Regards,
>Rashad
>
-- 

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

Re: [CMake] [CDash] CTEST_CUSTOM_WARNING_EXECPTION

2015-11-05 Thread David Cole via CMake
Looks to me like it might be (I'm hopeful) working at ignoring the
line which matches the expression ".*vcl_deprecated_header.h.*" ...

But then, the following line is:

 # warning "deprecated"

Since that line does not match any of your expressions, maybe that's
the one triggering this warning slipping through as unignored?


HTH,
D




On Thu, Nov 5, 2015 at 10:01 AM, Rashad M <mohammedrasha...@gmail.com> wrote:
> yes.
>
> On Thu, Nov 5, 2015 at 1:46 PM, David Cole <dlrd...@aol.com> wrote:
>>
>> Does your ctest -S script call ctest_read_custom_files
>> https://cmake.org/cmake/help/v3.4/command/ctest_read_custom_files.html after
>> ctest_configure?
>>
>>
>> On Thursday, November 5, 2015, Rashad M <mohammedrasha...@gmail.com>
>> wrote:
>>>
>>> Hello all,
>>>
>>> I have CTestCustom.cmake.in file in source tree with the following
>>> contents
>>>
>>>
>>> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in
>>>
>>> during ctest build CTestCustom.cmake file is getting generated inside the
>>> build tree.
>>>
>>> But however the warnings are not filtered out on the dashboard. For
>>> instance, see the dashboard submission
>>> http://dash.orfeo-toolbox.org/viewBuildError.php?type=1=206112
>>>
>>> and see the exception for vcl_deprecated_header
>>>
>>>
>>> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in#l69
>>>
>>> The warning appears on dashobard anyway. Can someone point me in the
>>> right direction. ?
>>>
>>> Thanks in advance.
>>>
>>>
>>> CMake Version:
>>> 2.8.12.2
>>>
>>> CDash Version:
>>> 2.2.3
>>>
>>> uname -a
>>> Linux ubuntu
>>>
>>>  3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64
>>> x86_64 x86_64 GNU/Linux
>>> --
>>> Regards,
>>>Rashad
>
>
>
>
> --
> Regards,
>Rashad
-- 

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


Re: [CMake] add_custom_command not triggered

2015-10-31 Thread David Cole via CMake
Oh wait, I read it wrong...

Try ${} to get the value of the variable. (It contains a file name, right?)


D



On Saturday, October 31, 2015, David Cole <dlrd...@aol.com> wrote:

> Because you're giving DEPENDS as a target name, this is only an ordering
> dependency, stating that the command should run after the target is built.
> But not necessarily re-build whenever the target is re-built...
>
> If you want to re-run the command based on a file changing instead, then
> use the full path to a file name as your DEPENDS argument. The downloaded
> file itself, or the extracted data file the command uses would probably be
> reasonable choices.
>
> Read the DEPENDS section of
> https://cmake.org/cmake/help/v3.3/command/add_custom_command.html
> carefully.
>
>
> HTH,
> David C.
>
>
> On Saturday, October 31, 2015, Nico Schlömer <nico.schloe...@gmail.com
> <javascript:_e(%7B%7D,'cvml','nico.schloe...@gmail.com');>> wrote:
>
>> After downloading a file with ExternalData_Expand_Arguments [1], I would
>> like to execute a command on the data to produce another file. So far, I
>> have
>> ```
>> ExternalData_Expand_Arguments(
>>   noshTestFetchData
>>   OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test/data/${file}}
>> )
>> ExternalData_Add_Target(noshTestFetchData)
>>
>> add_custom_command(
>>   OUTPUT ${CMAKE_BINARY_DIR}/test/data/pacman.e.2.0
>>   COMMAND decomp -p 2 ${CMAKE_BINARY_DIR}/test/data/pacman.e
>>   DEPENDS noshTestFetchData
>> )
>> ```
>> The file is downloaded alright, but the `add_custom_command` is never
>> triggered. Why not?
>>
>> This is with CMake 3.2.2.
>>
>> Cheers,
>> Nico
>>
>> [1] https://cmake.org/cmake/help/v3.3/module/ExternalData.html
>>
>
-- 

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

Re: [CMake] add_custom_command not triggered

2015-10-31 Thread David Cole via CMake
Because you're giving DEPENDS as a target name, this is only an ordering
dependency, stating that the command should run after the target is built.
But not necessarily re-build whenever the target is re-built...

If you want to re-run the command based on a file changing instead, then
use the full path to a file name as your DEPENDS argument. The downloaded
file itself, or the extracted data file the command uses would probably be
reasonable choices.

Read the DEPENDS section of
https://cmake.org/cmake/help/v3.3/command/add_custom_command.html carefully.


HTH,
David C.


On Saturday, October 31, 2015, Nico Schlömer 
wrote:

> After downloading a file with ExternalData_Expand_Arguments [1], I would
> like to execute a command on the data to produce another file. So far, I
> have
> ```
> ExternalData_Expand_Arguments(
>   noshTestFetchData
>   OUT_DATA DATA{${CMAKE_SOURCE_DIR}/test/data/${file}}
> )
> ExternalData_Add_Target(noshTestFetchData)
>
> add_custom_command(
>   OUTPUT ${CMAKE_BINARY_DIR}/test/data/pacman.e.2.0
>   COMMAND decomp -p 2 ${CMAKE_BINARY_DIR}/test/data/pacman.e
>   DEPENDS noshTestFetchData
> )
> ```
> The file is downloaded alright, but the `add_custom_command` is never
> triggered. Why not?
>
> This is with CMake 3.2.2.
>
> Cheers,
> Nico
>
> [1] https://cmake.org/cmake/help/v3.3/module/ExternalData.html
>
-- 

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

Re: [cmake-developers] Specifying a VS installation path explicitly

2015-10-27 Thread David Cole via cmake-developers
A simple source tree grep for "HKEY" (or even just "HK") will point you to
all the places CMake has registry key references in its source code...



On Tue, Oct 27, 2015 at 10:38 AM, Johannes Asal 
wrote:

> If it was actually using registry entries only for locating the VS
> installations it would be perfectly fine with me. But my observations
> indicate that it depends on environment variables as well. Could you point
> me to where that logic is implemented in the source code or the CMake
> modules?
>
> Mit freundlichen Grüßen / Best regards
>
> Johannes Asal
> Entwicklungsingenieur Software  |   Identification & Measuring Research &
> Development
>
>
>
> SICK AG  |  Nimburger Str. 11  |  79276 Reute  |  Germany
> Phone +49 7641 469-1460  |  johannes.a...@sick.de  |  http://www.sick.de
>
>
>
> SICK AG  |   Sitz: Waldkirch i. Br.  |   Handelsregister: Freiburg i. Br.
> HRB 280355
> Vorstand: Dr. Robert Bauer (Vorsitzender)  |  Reinhard Bösl  |  Dr. Mats
> Gökstorp  |  Dr. Martin Krämer  |  Markus Vatter
> Aufsichtsrat: Gisela Sick (Ehrenvorsitzende)  |  Klaus M. Bukenberger
> (Vorsitzender)
> --
>
> 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] include_external_msproject, add_dependencies and build type (debug/release)

2015-10-27 Thread David Cole via CMake
CMAKE_BUILD_TYPE is not typically used/useful with the Visual Studio
generators. You may want to look into using the CMAKE_CFG_INTDIR
variable instead.

https://cmake.org/cmake/help/v3.3/variable/CMAKE_CFG_INTDIR.html



On Tue, Oct 27, 2015 at 8:06 AM, Holzinger, Axel  (ALC NetworX GmbH)
 wrote:
> Hi list,
>
> I'm on my wits end with include_external_msproject, add_dependencies and 
> build type.
>
> This is the situation: I have a CMake project with an external static library 
> A which is included in the build via include_external_msproject, a static 
> library B and a binary C.
>
> B is depemding on A
> C is depending on B
>
> My upper (above the directories for B and C) CMakeLists.txt looks like this:
>
> include_external_msproject(A ${CMAKE_SOURCE_DIR}/A.vcxproj)
>
> The CMakeLists.txt for B has these (and other) parts:
>
> cmake_policy(GET CMP0046 cmp)
> if (NOT cmp STREQUAL "OLD")
> cmake_policy(SET CMP0046 OLD)
> endif ()
> add_dependencies (B A)
> cmake_policy(SET CMP0046 NEW)
> target_link_libraries(B ${CMAKE_BINARY_DIR}/Win32/${CMAKE_BUILD_TYPE}/A.lib)
>
> The CMakeLists.txt for C has these (and other) parts:
>
> target_link_libraries(C B)
>
> In reality there are othe libs too. I reduced complexity to make it easier to 
> understand the scenario.
>
> The stuff above works fine for CMAKE_BUILD_TYPE=Debug, meaning in Visual 
> Studio 2013 in the project build dependencies for B I see that it's depending 
> on A and so the build order is A first then B. The project build dependencies 
> for C say that the binary is depending on B and A and the build oreder is A 
> first, then B and then C.
>
> Perfect.
>
> But with CMAKE_BUILD_TYPE=Release I see that B is depending on A, but C is 
> ONLY depending on B, but NOT on A.
>
> Can anybody explain what's going on? Any hint would be greatly appreciated.
>
> Thank you
> Axel
>
> PS: I know that setting policies to OLD isn't the nice way, but I don't know 
> of any other solution the depend on a external Visual Studio project.
>
> --
>
> 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
-- 

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


Re: [CMake] CMake 3.3 and 3.2 bootstrap fails on OS X Yosemite

2015-10-01 Thread David Cole via CMake
The "-1" bz2 files are for Cygwin...

Try the plain old .tar.gz instead.


David

> On Oct 1, 2015, at 7:51 PM, Damian Rouson  
> wrote:
> 
> All,
> 
> Could someone advise me on building CMake from source on OS X 10.10.5 
> (Yosemite)?  At the bottom of this email is the tail of the output from the 
> following build script: 
> 
> #!/bin/bash
> version=3.3
> wget http://www.cmake.org/files/v$version/cmake-$version.0-1-src.tar.bz2 &&
> tar xvjf cmake-$version.0-1-src.tar.bz2 &&
> tar xvjf cmake-$version.0.tar.bz2 &&
> cd cmake-$version.0  &&
> ./bootstrap --prefix=${PWD} >&1 | tee build.log
> 
> An identical script completes successfully on Linux (Lubuntu).   The complete 
> output of the above script in the “build.log” file at 
> https://github.com/sourceryinstitute/AdHoc/tree/master/src/cmake/bug-.  A 
> link to the resulting “cmake_bootstrap.log” file is on the same page. 
> 
> I get the same error with CMake 3.2.3 and have reported this behavior in 
> CMake bug report 0015762 (https://cmake.org/Bug/view.php?id=15762).
> 
> 
> 
> Damian Rouson, Ph.D., P.E.
> President, Sourcery Institute
> http://www.sourceryinstitute.org
> +1-510-600-2992 (mobile)
> 
> 
> 
> 
> g++ 
> -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-/cmake-3.3.0/Bootstrap.cmk
>  
> -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-/cmake-3.3.0/Source
>  
> -I/Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-/cmake-3.3.0/Bootstrap.cmk
>  -c 
> /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-/cmake-3.3.0/Source/cmBootstrapCommands1.cxx
>  -o cmBootstrapCommands1.o
> In file included from /usr/include/dispatch/dispatch.h:51:0,
> from 
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
> from 
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
> from 
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
> from 
> /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-/cmake-3.3.0/Source/cmFindProgramCommand.cxx:16,
> from 
> /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-/cmake-3.3.0/Source/cmBootstrapCommands1.cxx:52:
> /usr/include/dispatch/object.h:143:15: error: expected unqualified-id before 
> '^' token
> typedef void (^dispatch_block_t)(void);
>   ^
> /usr/include/dispatch/object.h:143:15: error: expected ')' before '^' token
> /usr/include/dispatch/object.h:362:3: error: 'dispatch_block_t' has not been 
> declared
>   dispatch_block_t notification_block);
>   ^
> make: *** [cmBootstrapCommands1.o] Error 1
> -
> Error when bootstrapping CMake:
> Problem while running make
> -
> Log of errors: 
> /Users/rouson/Code/sourceryinstitute/AdHoc/src/cmake/bug-/cmake-3.3.0/Bootstrap.cmk/cmake_bootstrap.log
> 
> 
> -- 
> 
> 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
-- 

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

Re: [CMake] CDash [Safe Numerics] - Administration

2015-09-27 Thread David Cole via CMake
This message is sent when an unparseable xml file is submitted to CDash.
The email says the contents are as follows, with nothing (the empty string)
following... So, usually, this is some bot sending garbage to your CDash
url. There is nothing for you to do, but ignore these. If they are too
frequent, and coming from a suspicious IP address, you can ban submissions
from that IP address.

HTH,
David C.


On Sunday, September 27, 2015, Robert Ramey  wrote:

> I see that some people are posting results to my dashboard
> http://my.cdash.org/index.php?project=Safe+Numerics=1=1=buildstarttime/date=83=1%20year%20ago
> - but lately I’ve been getting the following message.  Unfortunately, the
> message doesn’t tell me what to change to make this work!  So I need some
> help.  Any suggestions appreciated.
>
>
> Begin forwarded message:
>
> From: CDash 
> Subject: CDash [Safe Numerics] - Administration
> Date: September 23, 2015 at 2:54:51 PM PDT
> To: ad...@cdash.org, ra...@rrsd.com
> Reply-To: nore...@cdash.org
>
> Object: Cannot create handler based on XML content
> An XML submission from 41.220.69.175 to the project Safe Numerics cannot
> be parsed. The content of the file is as follow:
>
> -CDash on my.cdash.org
>
>
> Robert Ramey
> Robert Ramey Software Development
> (805)569-3793
> ra...@rrsd.com
> www.rrsd.com
>
> --
>
> 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
-- 

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

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

2015-09-24 Thread David Cole via cmake-developers
Unfortunately, "pushd" is an inappropriate command to use when the
argument is quoted. It works just fine with "/" characters if the
argument is quoted...

For example:

C:\Users\davidcole>pushd C:\Windows\System32

C:\Windows\System32>pushd C:/dev
The syntax of the command is incorrect.

C:\Windows\System32>pushd "C:/dev"

C:\dev>

It would be better to use a test command that **actually** fails when
a "/" path is a quoted entity


HTH,
David C.




On Thu, Sep 24, 2015 at 9: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.
>
> -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 
> $ without ambiguity.  Please include test cases 
> for errors on relative paths (see Tests/RunCMake/GeneratorExpression).
>
> 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
-- 

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] Listing all targets

2015-09-14 Thread David Cole via cmake-developers
Finally getting back to this, hopefully can push to next this week,
and have this completed in time for the upcoming 3.4 release.

I have three questions before attempting my first merge-to-next for testing:

(1) I see how I can easily move "COMPONENTS" from
cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty
because I can access the global generator from cmState as well... To
move "VARIABLES" and "MACROS," though, I need access to the correct
cmMakefile in which the cmGetCMakePropertyCommand is running. Do I
need to pass the cmMakefile instance as a new parameter to
cmState::GetGlobalProperty, or is the correct Makefile instance
already available from the context of the cmState? (If so, it's
non-obvious to me from code analysis...) Steve, Brad? Any input on
this question?

(2) I will update the documentation of get_cmake_property to say these
are all also available via get_property(GLOBAL ... That's the correct
intent, right? All calls to get_cmake_property should have exactly the
same content as a corresponding call to get_property(GLOBAL?

(3) Is anyone concerned about adding a global property with the
somewhat generic name "TARGETS" ? Do we care if any projects out there
are already doing a set_property(GLOBAL with the name "TARGETS"? The
downside of a project doing so would be that when they try to read the
value back with get_property, CMake's implementation will overwrite
their set values with the list of all available CMake targets, which
may be different than what the project had set into the property.


Thanks for any feedback,
David C.




On Mon, Jul 20, 2015 at 9:30 AM, Brad King <brad.k...@kitware.com> wrote:
> On 07/17/2015 06:05 PM, David Cole via cmake-developers wrote:
>> Attached is a patch file of my first attempt. I can iterate some more
>> on this (better testing, add docs, clarify existing docs, address
>> anybody's comments, submit to stage) next week. Attached now in case
>> anybody wants to try it out over the weekend.
> [snip]
>>> I think the see also is relevant because it points to another way to
>>> get to a whole different set of "properties". Perhaps what they're
>>> looking for when they stumble upon get_cmake_property is actually
>>> target properties, which are only accessible via get_property.
>
> get_cmake_property is get_property with the GLOBAL scope, except that
> it looks like the special VARIABLES, MACROS, and COMPONENTS properties
> are hard-coded into get_cmake_property incorrectly.
>
> This should all be moved over to cmState::GetGlobalProperty and the
> new TARGETS property added there.  That method already has special
> handling for a few other properties too.
>
> Also the documentation of get_cmake_property should be updated to
> mention "global" properties.
>
> -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


Re: [cmake-developers] Making kwsys a proper library

2015-08-21 Thread David Cole via cmake-developers
Honestly, KWSys has always seemed like a boost-avoidance mechanism
from an outsider's perspective. Perhaps it should be replaced with
boost equivalents in projects that need to be packaged for Fedora.

I assume all the boost libraries are already packaged/available.


Fuel for the fire, ;-)
D



On Fri, Aug 21, 2015 at 9:27 AM, Brad King brad.k...@kitware.com wrote:
 On 08/20/2015 10:19 PM, Orion Poplawski wrote:
 The consensus of the FPC is that the current situation with KWSys is
 very undesirable.  While this approach may have been reasonable years
 ago with few consumers, it does not seem acceptable at this point.

 FWIW, the origin of this is the following:  Many, many projects have
 their own custom code for many of the things KWSys is doing, but they
 may not organize the implementations into a distinguishable library.
 This does not seem to be a problem for packaging these projects even
 though they could be using third-party libraries instead.

 We have several projects that all want some of these things as details
 of their implementation but we do not want to maintain a first-class
 library for them.  We could have had divergent implementations in
 each project like so many other unrelated projects do, but instead we
 decided to build infrastructure to share the common components of the
 source tree.  This gives our projects the benefits of common, well-
 tested infrastructure without the cost of maintaining a public-facing
 library for them.  If these implementations were not shared under the
 common KWSys banner then no one would have noticed that the projects
 appear to bundle a library.  How is this worse than other projects
 that do not share code at all?

 Yes, several components of KWSys appear to re-implement functionality
 that is now available in better third-party libraries.  However, much
 of it was added to our projects before those third-party libraries
 existed.  Things like the RegularExpression component came from other
 third-parties at the time who were also not providing first-class
 libraries for them.  Now they are kept in KWSys as a way to share the
 implementations among our projects at the source level.

 Any and all efforts by the KWSys maintainers to split out KWSys into
 proper libraries and perhaps pull out code that is only use by a single
 project into that project would be greatly appreciated.

 Some components of KWSys are present for historical reasons and
 can be factored out or removed now.  This will be a worthwhile
 cleanup regardless of the above discussion.

 be greatly appreciated if KWSys using projects would include in their
 tarballs only those components that they actually used.

 Prior to CastXML, KWSys has only been included in projects that are
 much, much larger than itself and use most of its components so its
 size has not stood out before.  I've now reduced the KWSys sources
 inside CastXML to the minimum it needs.  Further discussion on the
 CastXML side would be better held on its own mailing list.

 -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


Re: [CMake] Imported libraries and cross platform target names

2015-08-21 Thread David Cole via CMake
Find_library results are cached. If you want to re-find a potentially moved
library every time you run, you would have to unset the cache variable
prior to finding it.

D


On Thursday, August 20, 2015, Ette, Anthony (CDS) 
anthony.r.e...@controlsdata.com wrote:

 Ok so I’ve got this going now (kind of) but FIND_LIBRARY doesn’t seem to
 update when the specified PATH changes.  Since we are developing and
 releasing our own static libraries on a separate development cycle from the
 final applications, a final application may use a different library release
 than another.  This means the application developer needs a method to point
 to different library releases (different locations on the filesystem).
 We’ve always used environment variables for this and the developer issues a
 “workon” prior to developing an application.  The workon sets up all the
 necessary env vars but FIND_LIBRARY doesn’t update when the env var does.
 For example, using either method 1 or 2 below to set an internal cmake
 variable doesn’t do the trick for the FIND_LIBRARY command to pick up a new
 libtest file in the new location.





 1)  FILE(TO_CMAKE_PATH $ENV{LIB_DIR} LIB_D)

 2)  SET(LIB_D $ENV{LIB_DIR} CACHE STRING lib dir FORCE)



 FIND_LIBRARY(libtest NAMES test PATHS {LIB_D} NO_DEFAULT_PATH)







 I’ve also tried using the env string directly in the FIND_LIBRARY command
 as below, but the library being used in the build tree Makefiles still does
 not get updated.  I’ve also confirmed that the env var *is*  updated when
 CMake is rerun using MESSAGE command, so I believe it is merely a problem
 with triggering a change to the FIND_LIBRARY command.  How does this
 triggering work?  How can I force FIND_LIBRARY to check again each time
 CMake runs?



 FIND_LIBRARY(libtest NAMES test PATHS $ENV{LIB_DIR}
 NO_DEFAULT_PATH)





 Thanks,


 *Anthony Ette *Control Systems Engineer



 Rolls-Royce Controls and Data Services

 7661 N Perimeter Rd

 Indianapolis, IN 46241

 tel: +1 (317) 230-6943

 mob: +1 (317) 864-7975

 email: anthony.r.e...@controlsdata.com
 javascript:_e(%7B%7D,'cvml','anthony.r.e...@controlsdata.com');



 *From:* Parag Chandra [mailto:pa...@ionicsecurity.com
 javascript:_e(%7B%7D,'cvml','pa...@ionicsecurity.com');]
 *Sent:* Tuesday, August 18, 2015 3:08 PM
 *To:* Ette, Anthony (CDS); CMake@cmake.org
 javascript:_e(%7B%7D,'cvml','CMake@cmake.org');
 *Subject:* Re: [CMake] Imported libraries and cross platform target names



 Yes, very similar. When I set out to convert our existing build system,
 which consists of many individual .sln and .vcxproj files, I got a
 requirement that the developers do not all want to work out of the same
 “uber” Xcode workspace/VS solution that contains all of the projects. They
 want to continue working with solutions that contain only the library of
 interest plus its associated test project. So when a developer runs CMake,
 a dependency like “timer” may refer to another CMake-generated project
 within the current build system, or it may refer to an
 already-built/downloaded dependency of the same name.


 *Parag Chandra*
 Senior Software Engineer, Mobile Team
 Mobile: +1.919.824.1410

 https://ionic.com

 Ionic Security Inc.
 1170 Peachtree St. NE STE 400, Atlanta, GA 30309



 *From: *Ette, Anthony (CDS) anthony.r.e...@controlsdata.com
 javascript:_e(%7B%7D,'cvml','anthony.r.e...@controlsdata.com');
 *Date: *Tuesday, August 18, 2015 at 2:59 PM
 *To: *Parag Chandra pa...@ionicsecurity.com
 javascript:_e(%7B%7D,'cvml','pa...@ionicsecurity.com');, 
 CMake@cmake.org javascript:_e(%7B%7D,'cvml','CMake@cmake.org'); 
 CMake@cmake.org javascript:_e(%7B%7D,'cvml','CMake@cmake.org');
 *Subject: *RE: [CMake] Imported libraries and cross platform target names



 Thank you, I will take a look at find_library.  The static libraries are
 ones we build in-house but in a separate CMake-generated build system.  The
 reason we use a separate build system is because our common library code is
 used by all applications and, as such, is on a separate development cycle
 than the applications themselves.  In other words, while there may be
 advantages to combining them, I don’t think it would really make sense in
 our case….any thoughts?  Are you in a similar situation?




 *Anthony Ette *Control Systems Engineer



 Rolls-Royce Controls and Data Services

 7661 N Perimeter Rd

 Indianapolis, IN 46241

 tel: +1 (317) 230-6943

 mob: +1 (317) 864-7975

 email: anthony.r.e...@controlsdata.com
 javascript:_e(%7B%7D,'cvml','anthony.r.e...@controlsdata.com');



 *From:* Parag Chandra [mailto:pa...@ionicsecurity.com
 javascript:_e(%7B%7D,'cvml','pa...@ionicsecurity.com');]
 *Sent:* Tuesday, August 18, 2015 2:45 PM
 *To:* Ette, Anthony (CDS); CMake@cmake.org
 javascript:_e(%7B%7D,'cvml','CMake@cmake.org');
 *Subject:* Re: [CMake] Imported libraries and cross platform target names



 You just specify the “basename” of the library, so something like this:



 find_library 

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

2015-08-20 Thread David Cole via cmake-developers
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 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

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

2015-08-19 Thread David Cole via cmake-developers
But some existing replacements require forward slashes, we can't just to
native path everything blindly. I think you will have to special case the
bits which do need native paths.


On Wednesday, August 19, 2015, Kislinskiy, Stefan 
s.kislins...@dkfz-heidelberg.de wrote:

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

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] Does SET_TARGET_PROPERTIES(foo PROPERTIES INSTALL_RPATH /path1; /path2) still silently ignore path2?

2015-08-11 Thread David Cole via CMake
The final args to set_target_properties are any number of name/value pairs:

http://www.cmake.org/cmake/help/v3.3/command/set_target_properties.html

The only thing we could do there is look for an even number of args, and
catch possible problems half the time... I'm not sure if there are any
restrictions on property names, but for this command, and its historical
args composition, we are stuck with prop1 value1 prop2 value2 ... as the
final args.

Having said all that, there are some checks on the args to the function, so
it looks like you got unlucky with the number of paths in the prop value.
I would advise against playing roulette for a while... ;-)

https://github.com/Kitware/CMake/blob/422d3f68/Source/cmSetTargetPropertiesCommand.cxx#L36-L40


HTH,
David C.


On Tuesday, August 11, 2015, Dan Kegel d...@kegel.com wrote:

 Thanks.  Should set_target_properties throw an error if given too many
 arguments, to catch this problem?
 Am 10.08.2015 11:43 nachm. schrieb Nils Gladitz nilsglad...@gmail.com
 javascript:_e(%7B%7D,'cvml','nilsglad...@gmail.com');:

 On 08/11/2015 12:51 AM, Dan Kegel wrote:

 With cmake 2.8.12.2,

 SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH ${my_install_rpath})

 silently only obeys the first directory in the rpath, but

 SET_TARGET_PROPERTIES (foo PROPERTIES INSTALL_RPATH
 ${my_install_rpath})

 works.  Is it still that way in the latest cmake, and is there
 already a bug for this?  I looked,
 but didn't see one.


 It should still be this way.

 The command takes any number of key value pairs where each key and value
 are a single argument.

 A CMake list when expanded unquoted results in one argument per list item.

 When a list is quoted it is a single argument.

 Expansion of variables happens before the command itself gets its
 arguments.

 Without the quotes the first item in my_install_rpath will be interpreted
 as a value while the second will be a key etc.

 It might therefor be more of a language rather than command specific
 issue.

 One clean alternative is to use set_property() instead since unlike
 set_target_properties() it takes a single key but any number of value
 arguments.

 Nils


-- 

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

  1   2   3   4   5   6   7   8   9   10   >