Re: [cmake-developers] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

[Brad King via cmake-developers]

On 11/8/19 5:17 AM, Alexander wrote:
> /DEF:"E:/workspace/cmake_test_option/tesseract/bin/libtesseract.dir/Release/exports.def"
> is added by CMake automatically and I cannot control it (CMake first creates 
> a file
> objects.txt and then exports.def from it).

That behavior is not default, but activated by CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS:

  
https://cmake.org/cmake/help/v3.16/variable/CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS.html

The project you're building must be using that setting.  Find it and turn it 
off.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

[Brad King via cmake-developers]

On 11/5/19 7:30 AM, Alexander wrote:
> string(APPEND CMAKE_SHARED_LINKER_FLAGS " -DEF:\"foo_1.def\" 
> -DEF111:\"foo_1.def\"")

This was the first you've mentioned using more than one copy of the flag.

I tested with this:

```
string(APPEND CMAKE_SHARED_LINKER_FLAGS " 
-DEF:\"${CMAKE_CURRENT_SOURCE_DIR}/foo.def\"")
string(APPEND CMAKE_SHARED_LINKER_FLAGS " 
-DEF:\"${CMAKE_CURRENT_SOURCE_DIR}/bar.def\"")
```

With the command-line generators like Ninja or NMake Makefiles, both flags
appear.  With the Visual Studio generators, only the latter flag appears.

The reason is that CMake maps the `-DEF:` linker flag to the `.vcxproj`
file element `ModuleDefinitionFile` but only puts one value in it.  The
MSBuild documentation for that field is here:

  https://docs.microsoft.com/en-us/visualstudio/msbuild/link-task?view=vs-2019

and says "Specifies the name of a module definition file."  AFAIK it only
supports one value.  This is a limitation of MSBuild.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] These two generator expressions should be equivalent, but one working while the other not working. Bug?

[Brad King via cmake-developers]

On 10/24/19 12:18 AM, Alan W. Irwin wrote:
>  $
> 
>Expression did not evaluate to a known generator expression

The `*_COMPILER_ID` generator expressions are a hard-coded set
corresponding to the languages supported by upstream CMake:

* C_COMPILER_ID
* CXX_COMPILER_ID
* CUDA_COMPILER_ID
* Fortran_COMPILER_ID
* OBJC_COMPILER_ID   (new in 3.16)
* OBJCXX_COMPILER_ID (new in 3.16)

This is because the language name is part of the expression name.

In the `$` case, the language name
is one of the parameters.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CTest load balancing

[Brad King via cmake-developers]

On 10/16/19 10:05 AM, Wouter Klouwen wrote:
> Is the intent for CTest to specifically manage CPU load or system load
> overall?

I don't think a careful distinction was made at the time.

If Linux needs some updates to be consistent with other platforms
then that would be fine with me.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

[Brad King via cmake-developers]

On 10/9/19 6:04 PM, Alexander wrote:
> it deliberately ignores /DEF: which makes impossible to add /DEF: this easy
> (and for me preferable) way.

The code

```
string(APPEND CMAKE_SHARED_LINKER_FLAGS " 
-DEF:\"${CMAKE_CURRENT_SOURCE_DIR}/foo.def\"")
```

works fine for me.

So does this:


```
target_link_options(mySharedLib PRIVATE 
"-DEF:${CMAKE_CURRENT_SOURCE_DIR}/foo.def")
```

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

[Brad King via cmake-developers]

On 10/8/19 8:10 AM, Alexander wrote:
> I found that CMake ignores /DEF: option in CMAKE_SHARED_LINKER_FLAGS.
> I would like to know if this is an expected behaviour or a bug.

A module definition file can be passed as a normal source file and
CMake will automatically add `/DEF:...` to the link line as needed.

-Brad
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Revitalize --find-package mode?

[Brad King via cmake-developers]

On 10/2/19 9:24 AM, Nagy-Egri Máté Ferenc via cmake-developers wrote:
> to obtain dependency information is no longer maintained in CMake,
> or at least discouraged for new projects.

For reference, the `cmake --find-package` mode documentation you
mentioned is here:

* 
https://cmake.org/cmake/help/v3.15/manual/cmake.1.html#run-the-find-package-tool
  "This mode is not well-supported due to some technical limitations.
   It is kept for compatibility but should not be used in new projects."

There is an issue collecting some of the problems with it:

* https://gitlab.kitware.com/cmake/cmake/issues/14676

There is another issue discussing a possible alternative:

* https://gitlab.kitware.com/cmake/cmake/issues/17236

A key difference between the two approaches is that the latter actually
enables languages and inspects the toolchain to support things like
COMPILE_FEATURES and such.  However, the way all that information is
encoded in the imported targets created by `install(EXPORT)` is meant
to be consumed and transformed by CMake's generators.  It may not be
easy to extract it for external use.

I've just posted some additional links in the latter issue above:

* https://gitlab.kitware.com/cmake/cmake/issues/17236#note_634094

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Possible feature request concerning conditional linking support by generator expressions

[Brad King via cmake-developers]

On 9/24/19 5:02 PM, Alan W. Irwin wrote:
> I. Possible feature request
> 
> After reading through the generator-expression documentation at
> 
> it appears for my use case (see below) I need generator expressions of
> the form
> 
> $<$>:-pthread>
> $<$:-pthread>
> $<$:-Xcc-pthread>
> $<$:libbasename> (where libbasename is likely pthread)
> 
> where I guess (since I am pretty much a newbie with regard to detailed
> generator expressions) they would all be combined together in a list
> for a library target INTERFACE_LINK_LIBRARIES property.

I've opened an issue for that proposal and the associated use case:

* https://gitlab.kitware.com/cmake/cmake/issues/19757

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] EXCLUDE_FROM_ALL behavior change

[Brad King via cmake-developers]

On 9/24/19 8:12 AM, Charles Huet wrote:
> in CMake 3.14 the EXCLUDE_FROM_ALL option of add_subdirectory had a behavior 
> change.
> We are negatively impacted by this change, as we are in the same exact 
> scenario as
> this user: https://cmake.org/pipermail/cmake/2019-September/069978.html

Thanks.  We thought the change was backward compatible but perhaps not.
I've opened an issue:

  https://gitlab.kitware.com/cmake/cmake/issues/19753

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory

[Brad King via cmake-developers]

On 9/13/19 1:30 PM, Tushar Maheshwari wrote:
> Thanks for the quick response.
> I have my commits separated by file groups. I'll open small MRs
> collecting the related groups.

Thanks.  Please just keep a couple MRs open at a time so we don't
overwhelm the CI builders.  After some are merged you can open more.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory

[Brad King via cmake-developers]

On 9/13/19 12:58 PM, Kyle Edwards via cmake-developers wrote:
> On Fri, 2019-09-13 at 22:08 +0530, Tushar Maheshwari wrote:
>> I have pushed some sample commits to
>> https://gitlab.kitware.com/tusharpm/cmake/commits/smart_mem.
>>
>> If this is something I can pursue, I would appreciate a review of my
>> changes to better suit the project.
> 
> We have already made lots of progress in replacing manual delete's with
> std::unique_ptr's, and completing this modernization has been a goal of
> ours since we switched to C++11. I would very strongly encourage you to
> open a merge request with any progress you've made in this regard.

Yes.  Your branch changes a lot of areas and there are several other
rounds of refactoring going on so you may have trouble with conflicts.
I suggest grouping the changes (e.g. ExportSet) and opening a MR with
only one area.  Once that is merged open a new MR for another area.

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] escape double quote in generated file

[Brad King via cmake-developers]

On 8/30/19 10:36 AM, Eugene Karpov wrote:
> use it later for precompiled header generation.

FYI, CMake 3.16 will have first-class support for PCH:

  https://gitlab.kitware.com/cmake/cmake/merge_requests/3553

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] cmake-file-api and CTest

[Brad King]

On 8/22/19 2:41 PM, David Cole via cmake-developers wrote:
> The return code indicates a stack overflow. Let's hope it is not intended.

Thanks folks.  I opened an issue for that here:

* https://gitlab.kitware.com/cmake/cmake/issues/19629

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] ncurses sub-dir and include path

[Brad King]

On 8/1/19 6:35 PM, Christoph Grüninger wrote:
>> Why is that wrong?  As you said it has both `ncurses.h` and `curses.h`.
>> Even though they are symlinks one can still use them to compile.
> 
> CMake includes form.h, not (n)curses.h. So form.h is later not found,
> because after finding (n)curses.h in /usr/include the search is over.

Ah!  CMake's bundled `Source/CursesDialog/form/form.h` which I linked
earlier in this thread has all the logic to select the proper curses
header to include based on the FindCurses result.  However, IIUC you
are actually building with `CMAKE_USE_SYSTEM_FORM` enabled so that
CMake's `form.h` is not used.

This is actually a bug in our handling of `CMAKE_USE_SYSTEM_FORM`.
When that is turned on we should be looking for the location of
`form.h` rather than `*curses.h`.  Please open an issue tracker
entry for this.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] ncurses sub-dir and include path

[Brad King]

On 7/30/19 4:57 PM, Christoph Grüninger wrote:
> I always end up with /usr/include/ being the CURSES_INCLUDE_PATH.

Why is that wrong?  As you said it has both `ncurses.h` and `curses.h`.
Even though they are symlinks one can still use them to compile.

To ignore the symlinks one could configure with

  -DCURSES_INCLUDE_PATH=/usr/include/ncurses

to tell FindCurses to skip searching and just use that.  Once it has
that directory the computation of the other values may work.

>> That said, it's bad that the mess of conditions in the code I linked above
>> is even needed to use FindCurses.  It would be nice to add a policy to
>> change the FindCurses module to work in a more sane way.
> 
> Yes, this would be nice.

We have an open issue for this:

  https://gitlab.kitware.com/cmake/cmake/issues/16392

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] ncurses sub-dir and include path

[Brad King]

On 7/28/19 4:21 PM, Christoph Grüninger wrote:
> -include_directories(${CURSES_INCLUDE_PATH})
> +include_directories(${CURSES_INCLUDE_PATH}/ncurses/)

Why is that needed given the conditions here:

  
https://gitlab.kitware.com/cmake/cmake/blob/v3.15.1/Source/CursesDialog/form/form.h#L38-57
  
https://gitlab.kitware.com/cmake/cmake/blob/v3.15.1/Source/Checks/Curses/CheckCurses.c#L1-9

?

> The reason is, that curses.h and ncurses.h are present in /usr/include.
> Both are symbolic links to /usr/include/ncurses/curses.h.

What actually goes wrong?

That said, it's bad that the mess of conditions in the code I linked above
is even needed to use FindCurses.  It would be nice to add a policy to
change the FindCurses module to work in a more sane way.  However, we must
first determine what the proper behavior should be.  Should consumers
put the `ncurses/` part of the path in their `#include` lines or not?
If they do, how do they build against plain curses?

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] ninja generator does NOT use absolute paths at rules?

[Brad King]

On 7/22/19 4:47 PM, Claus Klein wrote:
> Than I realized , the ninja.rules files contains NO absolute paths
> to target source and header files.

Historically the Ninja ecosystem encourages use of relative paths.
There is an issue for this in CMake:

  https://gitlab.kitware.com/cmake/cmake/issues/13894#note_233789

and fixing it correctly depends on fixing another issue in Ninja:

  https://github.com/ninja-build/ninja/issues/1251

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] cmake-file-api and CTest

[Brad King]

On 7/7/19 5:04 AM, Nagy-Egri Máté Ferenc via cmake-developers wrote:
> I am trying to cook a CTest back-end to the Test Explorer UI extension
> for VS Code as a summer project and I thought of using the new cmake-file-api
> for it.

CTest's model of the test suite is distinct from CMake's model and may
be a superset of tests.  CMake 3.14 (which introduced fileapi) also
comes with a new ctest option for this.  Run

ctest --show-only=json-v1 -C Debug

in a build tree to get a machine-readable spec of the tests.  The
`-C Debug` argument can be used to specify the configuration for
which the set of tests is to be reported.

See documentation here:


https://cmake.org/cmake/help/v3.15/manual/ctest.1.html#show-as-json-object-model

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] target_link_libraries links mathlib as -lm rather than /libm.so, why?

[Brad King]

On 6/17/19 11:22 PM, Alan W. Irwin wrote:
> target_link_libraries(  /usr/lib/x86_64-linux-gnu/libm.so)
> 
> results in an actual link option "-lm".

Thanks.  I can reproduce that and have opened an issue with an explanation:

  https://gitlab.kitware.com/cmake/cmake/issues/19399

It occurs when the `.so` is a GNU ld script instead of an actual binary.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] No more emails from gitlab.kitware.com

[Brad King via cmake-developers]

On 4/15/19 3:56 AM, Sebastian Holtermann wrote:
> after changing my account (@sebholt) password in gitlab.kitware.com, I 
> don't get any emails from it anymore.  Login and everything web based 
> works, but no emails.  Did something change there?

Verify that your email address is still as expected.  Also visit

  https://gitlab.kitware.com/cmake/cmake

and look for the bell-shaped icon at the top.  That's the project-wide
notification setting for your user.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Pushing to gitlab.kitware.org from behind a ssl proxy

[Brad King via cmake-developers]

On 3/29/19 8:51 AM, Stuermer, Michael  SP/HZA-ZSEP wrote:
>  - pushing to kitware without 2FA fails
>  - pushing to kitware with 2FA fails

Try using gitlab's own deployment on "gitlab.com".  If that works
then we can investigate differences.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Source code ///! comments

[Brad King via cmake-developers]

On 3/26/19 8:28 AM, Sebastian Holtermann wrote:
> Looking through the source code I found various comments
> starting with "///!"
> If Doxygen is targeted, the comment should start with either "///" or
> "//!".

It's likely a typo.  For reference, I personally prefer `/** */`.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Trojan in latest release

[Brad King via cmake-developers]

On 3/22/19 9:56 AM, Brad King wrote:
>   
> https://github.com/Kitware/CMake/releases/download/v3.14.0/cmake-3.14.0-win64-x64.zip
> 
> and uploaded just `bin/cmake.exe` to virustotal.com: it does claim
> that `Trojan:Win32/Skeeyah.I` appears:
> 
> This is almost certainly a false positive.

I've replaced the binaries with a new build that does not trigger
the report.  The new `bin/cmake.exe` is identical in size and has
very few bytewise differences.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Trojan in latest release

[Brad King via cmake-developers]

On 3/21/19 12:21 PM, Cristian Adam wrote:
> Also worth mentioning that Virustotal has nothing on both 32 and 64 bit files:

I extracted

  
https://github.com/Kitware/CMake/releases/download/v3.14.0/cmake-3.14.0-win64-x64.zip

and uploaded just `bin/cmake.exe` to virustotal.com: it does claim that
`Trojan:Win32/Skeeyah.I` appears:

  
https://www.virustotal.com/#/file/c63217be5459bea702f905cb8a27097d89b94c5c1e25d09089a2f401da7a51ac/detection

This is almost certainly a false positive.  None of the other `.exe` files
in the zip have it.  Also `bin/cmake.exe` from the 3.14.0-rc* series of
binaries and the nightly binaries before and after the release all report
as clean.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] cmake server to cmake file api swicth

[Brad King via cmake-developers]

On 3/21/19 2:19 PM, Eric Noulard wrote:
> Can any CMake developer that has been participating in this new
> file api shed some light on the rational of this foreseen switch?
> I'm just curious about it. What was wrong/problematic with server mode?
> Does the new file api solves some IDE integration issue?

The file-api approach does not require a long-running CMake server
process and the associated memory consumption.  It also offers a better
story for format evolution (versioned queries, versioned replies).

The main improvement in the reported codemodel is the availability
of backtraces.

The tracking issue is here:

* https://gitlab.kitware.com/cmake/cmake/issues/18398

Issues that led to it include:

* https://gitlab.kitware.com/cmake/cmake/issues/17753
* https://gitlab.kitware.com/cmake/cmake/issues/17539

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Trojan in latest release

[Brad King via cmake-developers]

On 3/21/19 2:01 PM, kevin wrote:
> I have not actually seen the file, because windows defender is
> preventing the download from completing.

I just tried using MS Edge on an up-to-date Win 10 Pro with
Windows Defender enabled.  It is able to download and scan
the file, and finds nothing.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Trojan in latest release

[Brad King via cmake-developers]

On 3/21/19 12:31 PM, kevin wrote:
> Linked from https://camel.org/download

I'll assume you meant `cmake.org` there.

> Platform->windows win64-x64 installer: ...

That would be

  
https://github.com/Kitware/CMake/releases/download/v3.14.0/cmake-3.14.0-win64-x64.msi

I downloaded it and got a SHA-256 sum of

  4cbc62929f313d9890d377fa022753e9e5509e7afa3e16978127b7b2813633cf

which matches our published signatures.

What tool claims the binary contains Skeeyah?

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] signing Windows binaries

[Brad King via cmake-developers]

On 3/21/19 12:21 PM, Cristian Adam wrote:
> I think it would be great if Kitware would buy an authenticode
> certificate to sign the Windows builds. Is there a bug report on this?

I don't recall if there is an open issue but we are aware that the
Windows binaries could be signed and are not.  We do offer gpg-signed
SHA-256 hash files on the download page that can be used to verify
downloads.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Trojan in latest release

[Brad King via cmake-developers]

On 3/21/19 12:05 PM, kevin wrote:
> I just tried to install the latest release and noticed it contained Skeeyah.l

What is the URL of the binary you downloaded?
What is the sha256 sum of the installer file on your local disk?

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CDT] Improving CDT4 generator

[Brad King via cmake-developers]

On 3/20/19 5:20 PM, Alexander Neundorf wrote:
> On 2019 M03 20, Wed 13:53:49 CET Brad King wrote:
>> CMake's new file-api:
>>
>>   https://cmake.org/cmake/help/v3.14/manual/cmake-file-api.7.html
>>
>> That is now the intended way for third-party IDEs to display CMake projects.
> 
> so this is now preferred over the server-mode ?

Yes.  There have been a number of problems with server mode and it
will likely be deprecated in favor of the file-api.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] execute_process: how to detect TIMEOUT

[Brad King via cmake-developers]

On 3/20/19 11:53 AM, Joachim Wuttke wrote:
> The command execute_process has an option TIMEOUT.
> This option would be even more useful if one
> would notice when a timeout happened.
> Is there a way to tell from any of the outcome
> variables whether the process ran into timeout?

The RESULT_VARIABLE will contain a string mentioning "timeout".

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CDT] Improving CDT4 generator

[Brad King via cmake-developers]

On 3/19/19 4:57 PM, David wrote:
> since Eclipse 9.2 (or 9.1 do not remember), the CMake CDT4 Generator
> does not work as expected for C++ Project.
> 
> What is the best way to propose an update ?

Please see contribution instructions here:

  https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst

However, it would be better to work with Eclipse upstream to use
CMake's new file-api:

  https://cmake.org/cmake/help/v3.14/manual/cmake-file-api.7.html

That is now the intended way for third-party IDEs to display CMake projects.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] different behavior of cmake_minimum_required(3.0) and 3.1

[Brad King via cmake-developers]

On 3/19/19 11:57 AM, Rolf Eike Beer wrote:
> It has nothing to do with either the policies or the order of 
> cmake_minimum_required() and project().

Okay.  My order comment was a side note and should be corrected
either way.

> If I require version 3.0 it works, with 3.1 it fails.

See this code in FindPkgConfig:

  
https://gitlab.kitware.com/cmake/cmake/blob/v3.14.0/Modules/FindPkgConfig.cmake#L128-136

and the documentation note about CMAKE_MINIMUM_REQUIRED_VERSION:

  
https://cmake.org/cmake/help/v3.14/module/FindPkgConfig.html#command:pkg_check_modules

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Pushing to gitlab.kitware.org from behind a ssl proxy

[Brad King via cmake-developers]

On 3/19/19 2:21 AM, Stuermer, Michael  SP/HZA-ZSEP wrote:
> remote: HTTP Basic: Access denied
> fatal: Authentication failed for 
> 'https://gitlab.kitware.com//cmake.git/'

Try creating a personal access token to use during auth instead:

* https://gitlab.kitware.com/help/user/profile/personal_access_tokens.md
  "You can also use them to authenticate against Git over HTTP.
   They are the only accepted method of authentication when you
   have Two-Factor Authentication (2FA) enabled."

Otherwise, try using https auth from home without the proxy to make
sure it works and narrow the cause.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] different behavior of cmake_minimum_required(3.0) and 3.1

[Brad King via cmake-developers]

On 3/15/19 6:10 PM, Rolf Eike Beer wrote:
> I suspected it was a policy thing, so I tried this:
> 
> foreach(_p RANGE 21 54)
>cmake_policy(SET CMP00${_p} OLD)
> endforeach()

Only policies 51-54 were added between 3.0 and 3.1.  I suggest
testing with

cmake_minimum_required(VERSION 3.0)
cmake_policy(SET CMP0051 NEW)
cmake_policy(SET CMP0052 NEW)
cmake_policy(SET CMP0053 NEW)
cmake_policy(SET CMP0054 NEW)

and then trying different combinations.  My guess is CMP0054.

-

While looking at the source of that project, I noticed that
both `CMakeLists.txt` and `smtk-import/CMakeLists.txt` call
the `project()` command before `cmake_minimum_required()`.
The other order is preferred:

cmake_minimum_required(VERSION 2.8.11)
project(Subsurface)

because there are policies that affect project()'s behavior.
This order preference is documented by both commands.

I also noticed this code:

```
# don't process generated files - this is new in 3.10
if (POLICY CMP0071)
cmake_policy(SET CMP0071 OLD)
endif()
```

The cmake-policies(7) manual states that a policy should only
be set to OLD to silence warnings in frozen code bases or in
short-term circumstances.

The proper way to deal with CMP0071 is to set it to NEW
and set the `SKIP_AUTO*` properties on the sources that should
not be processed.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Exporting an imported target not supported?

[Brad King via cmake-developers]

On 3/12/19 9:55 AM, Lassi Niemistö wrote:
> is there a technical reason why it would not be a good idea to
> allow exporting the imported targets with all their properties?

We have not thought deeply through the semantics of that in general.
One of the main challenges is relocation handling.  Targets installed
by the project have known locations relative to the install prefix
and we expect that everything gets relocated together.  Targets from
external places have no such relationship.

If you're hard-coding paths anyway then I suggest simply linking via
absolute path instead of using an imported target.  If you do need
usage requirements, do it through a non-imported interface library:

```
add_library(extlib INTERFACE)
target_link_libraries(extlib INTERFACE /path/to/libextlib.so)
target_compile_definitions(extlib INTERFACE ...)
```

That can be installed and exported, and the importing side will
simply use the same absolute path.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Exporting an imported target not supported?

[Brad King via cmake-developers]

On 3/12/19 6:57 AM, Lassi Niemistö wrote:
> What to do in order to get rid of the extlib_interface workaround?
> I have not yet seen any means of "exporting" the properties of an
> imported target to tree2.

The file `cmake_test_system_lassi/tree1/Tree1Config.cmake` should
have code to re-create the extlib imported target with whatever
usage requirements it had for building tree1.  See the patch below.
In combination with removing all the `extlib_interface` code, the
`test.sh` script passes.

Generally imported targets are not manually created by project code.
Instead they come from `find_package(MyDependency)`.  Tree1Config
should repeat `find_package(MyDependency)` for public-facing
dependencies.  If you don't want to create a complete find module
for extlib, you can create a normal module that gets `include()`d
from both places.

See the docs here:

  
https://cmake.org/cmake/help/v3.14/manual/cmake-packages.7.html#creating-a-package-configuration-file

-Brad


```
diff --git a/cmake_test_system_lassi/tree1/Tree1Config.cmake 
b/cmake_test_system_lassi/tree1/Tree1Config.cmake
index 45f31f3..65248f3 100644
--- a/cmake_test_system_lassi/tree1/Tree1Config.cmake
+++ b/cmake_test_system_lassi/tree1/Tree1Config.cmake
@@ -1 +1,4 @@
+add_library(extlib SHARED IMPORTED)
+set_target_properties(extlib PROPERTIES IMPORTED_LOCATION 
/tmp/cmake_test_system_lassi/extlib/build/libextlib.so)
+target_include_directories(extlib INTERFACE 
/tmp/cmake_test_system_lassi/extlib/)
 include("${CMAKE_CURRENT_LIST_DIR}/Tree1Targets.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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Exporting an imported target not supported?

[Brad King via cmake-developers]

On 3/11/19 8:50 AM, Lassi Niemistö wrote:
> I cannot see any automatic rpath-link generation if I try the above. Should I?

Please post a minimal example tarball showing your case in practice.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Exporting an imported target not supported?

[Brad King via cmake-developers]

On 3/8/19 1:11 AM, Lassi Niemistö wrote:
> Am I just missing something and should be able to install the export
> of “extlib” without installing the target itself? Any reasoning why
> imported targets should not be possible to export? Any other solution
> ideas for passing the custom link dir of imported lib nicely from tree to 
> tree?

For your use case, CMake does have logic to generate -rpath-link flags
to find dependencies of linked shared libraries, but it needs to know
about these dependencies.

Here is how to handle this:

* Tree1 creates an imported target `extlib`.
  It is *not* installed or exported.

* Tree1 creates, exports, and installs, `lib1.so` with a dependency
  on `libextlib.so.1`.  This creates a `Tree1Targets.cmake` file.
  Tree1 should also provide a `Tree1Config.cmake` file that includes
  the targets file.  See


https://cmake.org/cmake/help/v3.14/manual/cmake-packages.7.html#creating-a-package-configuration-file

* Tree1Config.cmake *also* creates imported target `extlib`.
  This will be loaded in the context of dependents.

* Tree2 does `find_package(Tree1)`.  This loads `Tree1Config.cmake`
  which brings in both `extlib` and `lib1`.  Now the -rpath_link flag
  can be created by CMake.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Properly Documenting a CMake Module

[Brad King via cmake-developers]

On 2/12/19 6:37 PM, Timothy Wrona wrote:
> a way to document custom CMake modules so that they work with the
> "cmake --help-module " command

There is no way to do this. The only reason --help-module exists
at all is because prior to 3.0 the documentation was generated by
the CMake binary itself, and people were used to the option being
available.  It is only for builtin modules and only available for
legacy reasons, and may one day go away in favor of the man pages
and html docs.

The online docs, like those at https://cmake.org/cmake/help/v3.14
do publish a `/objects.inv` to support intersphinx:

  http://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html

This was done on request of some users so I haven't looked into how
that works, but one should be able to use sphinx to generate one's
own documentation and still cross-reference CMake's online docs.

If you get that working we'd welcome a MR to add docs describing how,
perhaps in

  https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/documentation.rst

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Help: Fix elseif/endif contradictions

[Brad King via cmake-developers]

On 2/11/19 2:06 PM, Juuso Linda Lapinlampi via cmake-developers wrote:
> -Per legacy, the :command:`else` and :command:`elseif` commands admit
> +Per legacy, the :command:`else` and :command:`endif` commands admit

Thanks, applied here:

  https://gitlab.kitware.com/cmake/cmake/merge_requests/2950

The MR description simply credits this thread, but the commit itself
preserves your nice commit message.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Shared library under Windows and CMake: DLL not found before installation

[Brad King via cmake-developers]

On 2/6/19 2:40 PM, Joachim Wuttke wrote:
> And combine it with
> 
> ```
> link_directories(BEFORE ${PROJECT_BINARY_DIR}/bin)
> ```
> 
> so that tests find the libraries?

No.  CMAKE_RUNTIME_OUTPUT_DIRECTORY only affects the locations of
the .dll files, not .a/.so/.lib.  Also CMake already knows where
the library files will be and links via absolute path.  Link
directories are almost never needed.

> Anyway, my problem is not at link time, but when _executing_ a test.
> Is there a canonical way of manipulating the Windows PATH from CMake?

No.  In general one should not depend on PATH for .dll locations
within your own project.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Shared library under Windows and CMake: DLL not found before installation

[Brad King via cmake-developers]

On 2/6/19 1:46 PM, Joachim Wuttke wrote:
> What is the minimally invasive adjustment
> to make the above build steps work under Windows?

Windows has no RPATH to help executables locate their shared
libraries.  The simplest solution is to put the .exe and .dll
files in the same directory (which can be different from the .lib
import libraries corresponding to the .dll files).

Add code like this at the top of your project:

```
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/bin)
```

This will make all executables go to that one directory, which
may require some other adaptation in your code for other platforms
too.  However, once done this will also put .dll files on Windows
in that directory.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake "find_package" command on a package that is not installed is unexpectedly successful

[Brad King via cmake-developers]

On 2/5/19 2:37 PM, Timothy Wrona wrote:
> Can anyone explain to me how "find_package" is able to find the Eigen 
> libraries
> even though they are just pasted into some arbitrary location that I never 
> told
> the example project about?

Eigen uses the CMake package registry feature:

  
https://bitbucket.org/eigen/eigen/src/a3be57987f/CMakeLists.txt?at=default=file-view-default#CMakeLists.txt-602:604

See docs here:

  
https://cmake.org/cmake/help/v3.13/manual/cmake-packages.7.html#package-registry

and step 6 of the find_package search procedure:

  https://cmake.org/cmake/help/v3.13/command/find_package.html#search-procedure

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMAKE_HOME_DIRECTORY vs CMAKE_SOURCE_DIR

[Brad King via cmake-developers]

On 1/29/19 5:37 AM, Joachim Wuttke wrote:
> how do these two relate to each other?

Their value is the same, but CMAKE_SOURCE_DIR is a normal CMake
variable intended for use by projects.  CMAKE_HOME_DIRECTORY
is an internal cache entry used to locate the source directory
when loading a `CMakeCache.txt` from a build tree.

CMAKE_HOME_DIRECTORY's presence in the modern documentation
looks historical and accidental.  It should either be removed
or updated to be described as internal to CMake.

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] $LIST_LENGTH{} syntax

[Brad King via cmake-developers]

On 1/22/19 1:31 PM, tors...@robitzki.de wrote:
> Currently, the Code that evaluates the ${}-Syntax only evaluates the key
> 
> const char* cmCommandArgumentParserHelper::ExpandSpecialVariable(

That's the pre-CMP0053 impl.

See cmMakefile::ExpandVariablesInStringNew for the modern impl.
Only with CMP0053 set to NEW can we consider the new syntax.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] $LIST_LENGTH{} syntax

[Brad King via cmake-developers]

On 1/22/19 10:55 AM, Marc CHEVRIER wrote:
> What about introducing a syntax similar to the version comparison:
> 
>   * LENGTH_EQUAL
>   * LENGTH_GREATER
>   * LENGTH_LOWER
>   * etc…
> 
> To use it:
> if (my_list LENGTH_EQUAL 1)
>   # do my stuff
> endif()

That's where this thread started.  Every new if() operator potentially
requires a policy, and there may be other places that the length of
a list is useful.

> Or introduce a more general syntax for list management as part
> of an expression:
> $LIST{,[,,…]}
> 
> Where ,  and  use same semantic as list command.
> To use it:
> of ($LIST{LENGTH,my_list} EQUAL 1)
>   # do my stuff
> endif()

Yes, something more extensible would be fine.  We need to be careful
not to slow down the variable reference syntax parser though.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] real functions (was: $LIST_LENGTH{} syntax)

[Brad King via cmake-developers]

On 1/22/19 10:28 AM, tors...@robitzki.de wrote:
> With `$CACHE{VAR}` and `$ENV{VAR}` we already have the syntax for calling a 
> „function“. 

No, there is no obvious way to pass arguments, handle nested quoting, etc.
The language was not designed for that.  That is a big can of worms I'd rather
not open just to solve the list length problem which is already only 2 lines.

> Once we have this, it would be possible to define $LIST_LENGTH in the CMake 
> language

Not as efficiently as a dedicated syntax for the only language construct
we have that resembles a data structure.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] $LIST_LENGTH{} syntax (was: Support for list length expression in if()-command?)

[Brad King via cmake-developers]

On 1/22/19 7:40 AM, Daniel Franke wrote:
> Whats about a Syntax like
> 
> ${list::LENGTH}

That would require dispatch after matching `${VAR}` syntax, and
that lookup is one of the hottest paths according to profiling.
We already have $ENV{} and $CACHE{} syntax.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] $LIST_LENGTH{} syntax (was: Support for list length expression in if()-command?)

[Brad King via cmake-developers]

On 1/22/19 7:09 AM, tors...@robitzki.de wrote:
>> Am 22.01.2019 um 12:42 schrieb Brad King:
>> Rather than a special `if` syntax, perhaps we could introduce an
>> explicit `$LIST_LENGTH{mylist}` syntax.  One would need to experiment
>> to see if modifying the variable expansion parser (under CMP0053 NEW
>> behavior only) to support this would have a significant performance
>> impact.
> 
> What would be a good experiment setup?

Using `cmake -P test.cmake` to run a script that does a lot of
variable evaluations without the proposed syntax, and later with it.

> How about adding the ability to add such function? Like:
> 
> procedure(LIST_LENGTH list)
>   list(LENGTH list length)
>   return(${length})
> endprocedure()

We don't have a syntax for invoking functions with return values.
That's a whole other discussion.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Support for list length expression in if()-command?

[Brad King via cmake-developers]

On 1/22/19 3:08 AM, tors...@robitzki.de wrote:
> three use cases:
> 
> - Checking for empty lists (I’ve showed him that this can be done
>   by a string compare).
> - Checking for lists having more than 1 entry
> - Checking for equal size of two lists. For example, if you want
>   to pass pairs or tuples to a function. (example: f(firsts seconds))

Rather than a special `if` syntax, perhaps we could introduce an
explicit `$LIST_LENGTH{mylist}` syntax.  One would need to experiment
to see if modifying the variable expansion parser (under CMP0053 NEW
behavior only) to support this would have a significant performance
impact.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Support for list length expression in if()-command?

[Brad King via cmake-developers]

On 1/14/19 4:21 AM, Torsten Robitzki wrote:
> if (LENGTH list GREATER 1)

An investigation will be needed to determine whether a policy
is needed to add this to the if() command to avoid possible
behavior changes for existing callers.

For reference, you asked this previously:

  https://cmake.org/pipermail/cmake-developers/2018-December/030941.html

I've almost never needed to test the length of a list in CMake
code.  It's not very common in my experience.  What is your
customer trying to do?

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] BISON_TARGET doesn't use CMAKE_CURRENT_BINARY_DIR as WORKING_DIRECTORY

[Brad King via cmake-developers]

On 1/8/19 6:44 AM, Brad King wrote:
> On 12/25/18 1:17 AM, Mingjie Xing wrote:
>> The BISON_TARGET will run bison command in CMAKE_CURRENT_SOURCE_DIR.
>>
>> So I just wonder whither it is better for  BISON_TARGET to use
>> CMAKE_CURRENT_BINARY_DIR as WORKING_DIRECTORY.
> 
> Unfortunately this went unnoticed for years after the module was
> added.  Changing it now would require a policy.

See proposed policy here:

  https://gitlab.kitware.com/cmake/cmake/merge_requests/2774

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] BISON_TARGET doesn't use CMAKE_CURRENT_BINARY_DIR as WORKING_DIRECTORY

[Brad King via cmake-developers]

On 12/25/18 1:17 AM, Mingjie Xing wrote:
> The BISON_TARGET will run bison command in CMAKE_CURRENT_SOURCE_DIR.
> 
> So I just wonder whither it is better for  BISON_TARGET to use
> CMAKE_CURRENT_BINARY_DIR as WORKING_DIRECTORY.

Unfortunately this went unnoticed for years after the module was
added.  Changing it now would require a policy.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Test for list size

[Brad King via cmake-developers]

On 12/12/18 7:01 AM, Torsten Robitzki wrote:
> we have often the need to test for a minimum list size
> 
>   list(LENGTH list list_size)
>   if (list_size GREATER 1)
> 
> This happens so much

I've almost never needed to test the length of a list.
What are you trying to do?

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Slowdown of nightly builds

[Brad King via cmake-developers]

On 12/12/18 7:15 AM, Rolf Eike Beer wrote:
> I noticed that for a few weeks the builds on my machines now take much longer 
> to complete, without any particular change in my setup.
> The change in the dashboard can be seen on the dashboard between 
> 2018-11-09 and 2018-11-10.

Thanks!  I had noticed that on several machines too but had not found
a specific day.  This is due to a major performance regression.

I've narrowed the problem further and opened an issue:

  https://gitlab.kitware.com/cmake/cmake/issues/18700

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug

[Brad King via cmake-developers]

On 12/9/18 8:09 AM, Marc CHEVRIER wrote:
> The real question is how to manage cleanly target specific flags
> overriding global or directory defaults?

All the optimization and warning flags currently handled by
`CMAKE__FLAGS[_]` need to have abstractions
introduced (e.g. target properties or something) and the
defaults re-thought.  Transition can be handled via a policy.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] A dashboard that reveals a ctest issue on Windows when there are no tests

[Brad King via cmake-developers]

On 12/5/18 5:01 PM, Alan W. Irwin wrote:
> But I still don't understand exactly how ctest is run from cmake.  Assuming 
> the
> "test" target (which I have never tried) runs the "all" target and then ctest,
> I guess
> 
> cmake --build . --config Debug --target test
> 
> would run ctest indirectly after the "all" target was built

cmake does not run ctest.  ctest is driving the dashboard client build.
First it configures the project.  Then it builds the project.  Then it
runs the tests.  The "build the project" step means it needs to run the
native build tool.  ctest uses "cmake --build . --config Debug" to do
that.  The native build tool somehow exits non-zero, and "cmake --build"
returns that error code.  As far as "ctest" knows, "cmake --build ..."
is the build tool, and it exited with non-zero.  That is why the message
appears.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] A dashboard that reveals a ctest issue on Windows when there are no tests

[Brad King via cmake-developers]

On 12/4/18 4:08 PM, Alan W. Irwin wrote:
>   Build Warnings (1)
> 
> *** WARNING non-zero return value in ctest from: 
> C:\cmake-3.13.1-win64-x64\bin\cmake.exe

That's in the "Build" section and indicates that the build command
exited with non-zero status.  If you want to try to reproduce that
by hand, run the `cmake --build . --config Debug` command rather
than `ctest`.

`cmake --build`'s exit code just forwards from the native build tool.
It may be that MSBuild has chosen to exist with non-zero for some reason.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] building host tools during cross compiliations (was: dependencies of cross compiliations)

[Brad King]

On 11/27/18 5:28 AM, Rolf Eike Beer wrote:
> Then I came up with:
> 
>add_host_build("relative source dir" "build dir" [VARS])
> 
> This would create an entirely new CMake scope (with it's own 
> CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir", 
> and would not take the CMAKE_TOOLCHAIN_FILE into account.
[snip]
> My idea would be that things added by add_executable() inside such a
> sub-build are visible as targets from the outer build.

For reference, some projects are already using the ExternalProject
module to approximate that approach and bring in the host tools as
imported executable targets.  The actual host build is viewed as
a custom target from the cross-compiled project.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] ENV{SOURCE_DATE_EPOCH}

[Brad King]

On 11/20/18 4:13 PM, Oleh Kravchenko wrote:
> I don't like idea to cover "cmake && make" with special bash script,
> just to export SOURCE_DATE_EPOCH.

SOURCE_DATE_EPOCH was created for use by packagers where tools
already wrap the build.  By making it an environment variable
packagers could jump through any number of build system layers
with no patching.

Build systems configure compilers with command-line flags, not
environment variables.  If you want to do this from within the
build system then GCC could be taught a new option for that.

You could try hacking it with `CMAKE__COMPILER_LAUNCHER`:

  https://cmake.org/cmake/help/v3.13/variable/CMAKE_LANG_COMPILER_LAUNCHER.html

e.g. -DCMAKE_C_COMPILER_LAUNCHER='env;SOURCE_DATE_EPOCH=1' or

```cmake
set(CMAKE_C_COMPILER_LAUNCHER env SOURCE_DATE_EPOCH=1)
```

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] ENV{SOURCE_DATE_EPOCH}

[Brad King]

On 11/20/18 10:51 AM, Oleh Kravchenko wrote:
> CMake should pass this variable to build tool (GNU Make, Ninja, ...).

CMake doesn't invoke the build tool to build the project.
The workflow is "run cmake, then run make".

With the Makefile and Ninja generators it is up to the user to
provide the environment for the toolchain to operate as desired.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] option to prevent in-source builds

[Brad King]

On 11/09/2018 07:28 AM, Taylor Holberton wrote:
> A lot of projects that use CMake already have a `./cmake` directory,
> I would think `./cmake/init.json` would fit nicer as opposed to the
> hidden directory.

We could have a list of supported places so projects can choose.

> I would prefer an init file be written as a CMake file instead of JSON.

We need to be able to load the file without initializing much.
If it is a CMake language file then people will try to write `if`
conditions to check things that we wouldn't provide access to at
that point.  The idea of this file is to have a purely declarative
specification.  A format like JSON will work well for that.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] option to prevent in-source builds

[Brad King]

On 11/09/2018 05:34 AM, Joachim Wuttke wrote:
> include(PreventInSourceBuilds)
> 
> to protect users (and myself) from unintentionally running CMake
> in the source directory.
> 
> Would you consider adding this little module to the CMake code base?

If we are going to offer an upstream solution for this I think
it should be done in a way that avoids ever creating any files
(like CMakeCache.txt or CMakeFiles) in the first place.  This
could be achieved by looking for a `.cmake/init.json` file
at the top of the source tree with declarative information
about the project's preferences.  One of those settings could
reject in-source builds.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake, Ninja and Clang on windows?

[Brad King]

On 11/06/2018 05:57 AM, Tobias Hunger wrote:
> we are currently trying to support Clang (without the -cl;-) on
> Windows. This fails since CMake adds extra compiler flags to the
> command line which are not in the expected format.

Clang with a GNU-like command targeting the MSVC ABI is not supported.
See this issue:

  https://gitlab.kitware.com/cmake/cmake/issues/16439

The MSVC-like command-line (with -cl) works fine.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] KWSys build warnings on the "merlin" platform

[Brad King]

On 10/23/2018 06:37 PM, Alan W. Irwin wrote:
> look at those build warnings which
> repeatedly show up on the "merlin" report for the the KWSys dashboard

The warnings come from code generated by CMake.  You're driving the
builds with CMake 3.7 which still generated code on which gcc 8 warns.
CMake 3.11 has the fix.  If you drive with that or higher instead then
the warnings should go away.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] cmake checkfortran fails with Flang

[Brad King]

On 10/22/2018 07:45 PM, blubee blubeeme wrote:
> There's a newly open sourced fortran compiler flang: 
> https://github.com/flang-compiler/flang
> 
>     /usr/local/bin/flang -cpp    -E testFortranCompiler.f ...
> 
> the fortran compiler does work if you remove the -E flag from the the 
> compilation command.
> 
> Is this an issue something that can get some attention?

It's trying to pass both -cpp and -E to get preprocessing.

Please open an issue tracker entry for this.

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Python bindings for CTest

[Brad King]

On 10/19/2018 11:16 AM, Jonathan R. Madsen wrote:
> I just include header files and link to y'all's library like one
> does with any other API. 

As a matter of policy we do not offer any stable API, SDK, headers,
or libraries to be linked for exposing CMake internals.  Any external
package that tries to do this must take responsibility for updating
as we make internal changes.

The syntax of CTestTestfile.cmake files is much more stable.

If your goal is to submit to CDash, one could generate the .xml
files directly from python and not need CTest at all.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Python bindings for CTest

[Brad King]

On 10/18/2018 11:22 PM, Jonathan R. Madsen wrote:
> I have created some Python bindings for CTest. The goal was to
> create an easy way for Python projects that I work with to be able
> to wrap their Python compilation log (if there was one), dynamically
> generate CTests and/or wrap their existing testing commands, do any
> additional testing analysis (in Python), etc. and then submit the
> logs, notes, plots, etc. to CDash without requiring them to overhaul
> any of their existing build or testing systems. 
> 
> Is there any interest in this development?

Neat.  Have you published these anywhere?

Does this make modifications to CTest itself, or is this all
going through CTestTestfile.cmake generation?  I don't think we
can have "ctest" itself link to python libraries.

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Generalized verbose option for cmake --build.

[Brad King]

On 10/18/2018 11:48 AM, Ray Donnelly wrote:
> Why do I need to know the necessary verbose flag to make each back-end
> that cmake --build calls emit more information? If forces my build
> script to switch on the platform in a really ugly way for something
> I'd consider a very important feature (you already hardcode various
> things to enable cmake --build to work, so why not this as well?)
> Something like cmake --build --verbose would be good.

There is work on that here:

  https://gitlab.kitware.com/cmake/cmake/merge_requests/2129

but it has stalled.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] [ANNOUNCE] CMake 3.13.0-rc1 is ready for testing

[Brad King]

On 10/09/2018 02:00 PM, Rolf Eike Beer wrote:
> Seems like you missed one part of the announcement mail ;)
> 
> Policies
> ==

The announcement comes from the release notes, and all policies
are mentioned there in relevant bullets.  We've never called them
out separately in such notes.  One can always see the list here:

   
https://cmake.org/cmake/help/v3.13/manual/cmake-policies.7.html#policies-introduced-by-cmake-3-13

separated by version.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] FindLua.cmake module does not find a locally built lua library

[Brad King]

On 09/24/2018 01:05 PM, Alan W. Irwin wrote:
>> On 09/22/2018 07:09 PM, Alan W. Irwin wrote:
>>> 2. Use the NAMES_PER_DIR option in the find_library command.
>> This is the correct fix.
>>
> I agree.

Please see

  https://gitlab.kitware.com/cmake/cmake/merge_requests/2412

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] FindLua.cmake module does not find a locally built lua library

[Brad King]

On 09/22/2018 07:09 PM, Alan W. Irwin wrote:
> 2. Use the NAMES_PER_DIR option in the find_library command.

This is the correct fix.

The versioned names need to go first to try to match the headers.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Today's PLplot contract has failed with missing Linux default .so suffix on modules

[Brad King]

On 09/18/2018 06:07 PM, Alan W. Irwin wrote:
> Just in case this has been fixed already where should I check for
> obvious CMake fix activity before reporting such issues?

Thanks.  That failed yesterday too but it slipped by because there
were many other failures to sort through while selecting a subset
of tested topics to merge.

Here is a fix and test case:

  https://gitlab.kitware.com/cmake/cmake/merge_requests/2402

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Automatically set policies for shipped modules

[Brad King]

On 09/17/2018 09:14 AM, Craig Scott wrote:
> We may also need to be careful about CMP0011

The policy scope added for our own modules can be marked as a "weak"
scope.  This means that specific policies can be set when the scope
is first opened in C++ code, but policy settings inside the scope will
leak out to the parent scope.  This inner "weak" scope can be added
to apply CMP0057 and such whether or not the main inclusion has its
own strong scope.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Automatically set policies for shipped modules

[Brad King]

On 09/17/2018 04:01 AM, Rolf Eike Beer wrote:
> I suggest that every module included from the CMake installation is 
> considered clean for whatever we do and automatically gets a policy 
> scope push/pop right from the C++ level.

That's fine with me for policies like CMP0057 that affect the
CMake language features.  We can't do that for every policy
because some policies affect the way modules behave for the
calling project.

When include() or find_package() establishes the policy scope
for the included module we can inject a few settings.

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Build warnings for CMake 3.12.2

[Brad King]

On 09/08/2018 04:26 PM, Alan W. Irwin wrote:
> For g++ version 8.0.2 from Debian Buster, I
> recently noticed the following (bootstrap) build warnings for CMake-3.12.2:
> 
> /home/software/cmake/cmake.git/Source/CursesDialog/cmCursesLongMessageForm.cxx:50:10:
>  warning: ‘char* strncpy(char*, const char*, size_t)’ specified bound depends 
> on the length of the source argument [-Wstringop-overflow=]

These have been fixed in `master`:

  https://gitlab.kitware.com/cmake/cmake/merge_requests/2244

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] The "cmake_host_system_information" Command

[Brad King]

On 09/01/2018 08:50 PM, Taylor Holberton wrote:
> create non-trivial variables that make queries when they are expanded

I understand the proposal but I don't think we should do that.
The variable expansion logic is already one of the hottest
parts of the code shown in profiling.  Adding dispatch for
special variables will only make it slower for everything else.

Also, it is not unreasonable for long operations to be called out
by more explicit commands in the code.

Furthermore, some queries may have parameters.  The command can
do that.  Squeezing everything into a variable name won't work
well.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] OpenCL language support (was: Compiler dependencies with Unix Makefiles)

[Brad King]

On 08/25/2018 02:08 PM, jerry@web.de wrote:
> new Compiler to CMake which compiles and links OpenCL files (file ending .cl)

Will that be done via `enable_language(OpenCL)`?  How might it work
on VS and Xcode?

> What is the reason that CMake uses its own mechanism with Unix Makefiles
> instead of relying on the compiler?

We support compilers that don't have such options and have done so since
before many of today's compilers gained support.

> Is it possible to configure CMake to use -MMD -MF with Unix Makefiles?

I've long wanted to see the Makefile generators converted to that
approach when using compilers that support it, but have never found
time to do it.

> If not, is it possible to tell cmake_depends to understand .cl files?

In principle yes, but in the long run it would certainly be better
to use the depfile approach.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Fwd: Build flags not applied during compiler testing on Ubuntu

[Brad King]

On 08/22/2018 02:43 PM, Richard Shaw wrote:
> Ok, I haven't gotten any responses from the user mailing list so hopefully 
> someone here can help me...

I responded on the user list.  It's only been one day anyway.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Quiet option for cmake

[Brad King]

On 08/21/2018 05:04 PM, Craig Scott wrote:
> A user has recently been asking about reducing the output coming from a
> FetchContent population when nothing needs to be done
> Because this is implemented as a sub-build, you always see the following
> 
> -- Configuring done
> -- Generating done
> -- Build files have been written to: ...

Isn't that output coming from the invocation here:

  
https://gitlab.kitware.com/cmake/cmake/blob/v3.12.1/Modules/FetchContent.cmake#L776-781

rather than inside ExternalProject?

Why is that output not always captured?

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Enabling SSL support by default when building CMake from source

[Brad King]

On 08/09/2018 08:54 AM, Craig Scott wrote:
> or is it just that the logic hasn't been added to try to enable
> it by default if available?

Mostly that.

On Windows and macOS we already get SSL by default because curl
just uses the OS-provided APIs.  This issue occurs only when we
need to find OpenSSL.

Since commit v3.6.0-rc1~301^2 (Automatically use OpenSSL by default
on Linux and FreeBSD if available, 2016-02-26) we try to enable
SSL by default on Linux and FreeBSD.  Its commit message explains
why we didn't do that for other platforms (too easy to find an
OpenSSL library that is not compatible with the target compiler).
A sophisticated try_compile may be needed to determine whether
enabling it will compile and link properly.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Darwin nightly builds

[Brad King]

On 08/07/2018 02:56 AM, Martin Sander wrote:
> the last nightly build for Mac in https://cmake.org/files/dev/?C=M;O=D
> is dated 2018-07-30, the other systems are there.

Thanks.  The problem was introduced just before I took time off so the
failing entry on our nightly testing dashboard went unnoticed.  I've
opened an issue for it:

* https://gitlab.kitware.com/cmake/cmake/issues/18245

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Compile flags depending on source file property

[Brad King]

On 08/03/2018 07:12 PM, Simon Richter wrote:
> string(APPEND CMAKE_CXX_FLAGS
> "$,${WARN_SHADOW_OFF},${WARN_SHADOW_ON}> ")

The generators put the project-/target-wide flags in a place that
does not depend on the source being compiled so there would be no
way to evaluate that.  On some generators per-source flags produce
a huge slowdown in the build (e.g. VS) so splitting up the settings
for every source is not practical.

We already run into this in the COMPILE_LANGUAGE generator expression:

  https://cmake.org/cmake/help/v3.12/manual/cmake-generator-expressions.7.html

See the note there about how it is handled on VS and Xcode.

> The only way I can think of doing this would be to remove the global
> warning flag definitions from the toplevel CMakeLists.txt

Per-source flags are placed after the target-wide flags on the command
line so you could just keep -Wshadow by default and then add -Wno-shadow
to the COMPILE_FLAGS source file property of the generated sources.

Alternatively you could use an object library for all the generated
sources and then set its target-wide flags to use "-Wno-shadow", or
even "-w".

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMAKE_C_COMPILER_ARG# not documented?

[Brad King]

On 07/19/2018 11:58 AM, Robert Dailey wrote:
> I can't remember where I heard about these CMake variables, but in one
> of my toolchain files I do this:
> 
> set( CMAKE_C_COMPILER_ARG1 -m32 )
> set( CMAKE_CXX_COMPILER_ARG1 -m32 )

They are not documented because they are internal implementation
details.  Projects should not be setting them.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] ctest - how to reset default regex error list

[Brad King]

On 07/18/2018 03:26 PM, Michal Wozniak wrote:
> Is there a way to have a completely new error regex list?  

No, due to the appending logic you found.  Some new option would need
to be added to fully replace the list.

If you use CTEST_USE_LAUNCHERS the default list is much reduced.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Regenerating yacc/lex files

[Brad King]

On 07/06/2018 10:49 AM, Devin Nakamura wrote:
> I was wondering why the option to regenerate the lexer/parser sources
> was removed. I tracked it down to this pull request which deals with
> clang tidy warnings in the code
> (https://gitlab.kitware.com/cmake/cmake/merge_requests/775). I was
> wondering if there was a reason behind the removal of the option / if
> anyone would object if it was added back in.

It was removed by commit 8927e913f780fa62c540063b8a5cfe0dcbfdd288
to simplify refactoring and moving of files into Source/LexerParser.

It's been replaced by two scripts:

Utilities/Scripts/regenerate-lexers.bash
Utilities/Scripts/regenerate-parsers.bash

These can be run by hand after modifying the lexer or parser inputs.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Alternative CMake Syntax

[Brad King]

On 07/04/2018 01:08 PM, Taylor Holberton wrote:
> I've been thinking about designing a new syntax for CMake

Fair warning: Upstream is not outright opposed to a new language but
it will take a lot to make something like that upstreamable, assuming
we even find time to consider it in depth.

> that better expresses some of the functionality that I've seen in
> modern CMake code. I've started a CMake parsing library and plan
> on using it to design the new syntax while maintaining support for
> the traditional syntax as well.

A major obstacle to replacing the language is separating the code model
representation from the current language.  Some work has been done to
factor it out into a representation that can be used by the generators
that is not tied to the implementation of the current language, but more
work is needed and the original contributor working on that is no longer
active.  Search back through the dev list archives for posts by Stephen
Kelly talking about where his work left off.

If a new input language were to be introduced it should fix some of the
fundamental problems with the current approach.  These include:

* Each directory and its included files must be processed serially
  due to the imperative language with side-effects.  This means we
  can never make the implementation parallel.

* The imperative form of the language also means that IDEs cannot
  easily edit the build specification through GUI actions.  If at
  least things like a list of sources were doable in a declarative
  way that could help.

When thinking about alternative approaches before I've considered
the idea of having most of the build spec be declarative/functional
(no side effects) and then having an imperative part that computes
parameters to evaluate conditions and expressions within the main
spec.  The main spec could then be updated by IDEs in a structured
way, evaluated in parallel, etc. while the imperative part could
handle system introspection, configure-time file generation, etc.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] 3.12.0-rc1: C# project outputting as a "vcxproj" (C++ project)

[Brad King]

On 06/26/2018 11:34 AM, Robert Dailey wrote:
> I'm happy to do that. I assume you would require an MCVE for that bug?
> If so it will take me considerably longer, as I don't have a lot of
> time to build a reproducible example from scratch. I'll do my best,
> though.

Even without a MCVE it's worth filing.  If you produce one later
and the issue hasn't been resolved then you can add it.

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 3.12.0-rc1 is ready for testing

[Brad King]

On 06/25/2018 01:56 PM, Raffi Enficiaud wrote:
> would it be possible to add the following to the release notes?
> 
> * FindMatlab now supports the Matlab Runtime Compiler (MCR) for
>compiling and linking matlab extensions. The MCR does not
>consume any license and is free to download.

Added here:

  https://gitlab.kitware.com/cmake/cmake/merge_requests/2173

We should have done that as part of the original work:

  https://gitlab.kitware.com/cmake/cmake/merge_requests/1970

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] 3.12.0-rc1: C# project outputting as a "vcxproj" (C++ project)

[Brad King]

On 06/26/2018 10:25 AM, Robert Dailey wrote:
> To fix this issue for now I had to do this:
> 
> set_property( TARGET ${project_name} PROPERTY LINKER_LANGUAGE CSharp )
> 
> I don't remember having to explicitly tell CMake that the project is
> CSharp in the past; it was always able to deduce it before. Is this
> considered a symptom of a bug? Or is this required behavior? To be
> honest, I'm not sure what criteria is used by CMake to deduce the
> linker language of targets, especially in the C# case. It appears that
> introducing a link-level dependency from a C# project to a Managed C++
> project, forces the parent project to be C++ as well.

Please open an issue for that.

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] cmake on AIX

[Brad King]

On 06/19/2018 12:17 PM, REIX, Tony wrote:
> So, it looks like cmake gets data for the CMAKE_REQUIRED_LIBRARIES
> from these 2 aboves places, but it does not transform the " " blank 
> separators by ";" ?!!

It's MariaDB's CMake code that is doing that, not CMake itself.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] cmake on AIX

[Brad King]

On 06/19/2018 11:48 AM, REIX, Tony wrote:
> However, we've found yet no information about how to:
> 
>    a) run one test,
> 
>    b) get more traces,

ctest -R $regex_matching_tests_to_run -V

>    c) know where are the logs.

See the Testing/* directory.  When not running in dashboard
client mode there isn't much logged though.

> CMake Error at 
> /opt/freeware/src/packages/BUILD/mariadb-10.3.1/64bit/CMakeFiles/CMakeTmp/CMakeLists.txt:14
>  (add_executable):
>   Target "cmTC_d6385" links to target "-L/opt/freeware/lib
>   -blibpath:/opt/freeware/lib::/usr/lib:/lib -I/usr/include
>   -I/opt/freeware/include -L/opt/freeware/lib
>   -blibpath:/opt/freeware/lib:/usr/lib:/lib -bmaxdata:0x8000 -brtl
>   -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lpthreads" but the target was
>   not found.  Perhaps a find_package() call is missing for an IMPORTED
>   target, or an ALIAS target is missing?
> 
> CMake Error at /opt/freeware/share/cmake/Modules/CheckSymbolExists.cmake:87 
> (try_compile):
>   Failed to generate test project build system.
> Call Stack (most recent call first):
>   /opt/freeware/share/cmake/Modules/CheckCXXSymbolExists.cmake:39 
> (__CHECK_SYMBOL_EXISTS_IMPL)
>   plugin/auth_gssapi/CMakeLists.txt:24 (CHECK_CXX_SYMBOL_EXISTS)

I suspect mariadb's source is setting CMAKE_REQUIRED_LIBRARIES
to a space-separated value instead of a ;-separated value.

See the code here:

  
https://github.com/MariaDB/server/blob/ed0b84a027/plugin/auth_gssapi/CMakeLists.txt#L22-L24

It assumes GSSAPI_LIBS is ;-separated, but the cache entry you
quoted is a command-lien string with spaces.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Using pkgconf

[Brad King]

On 06/12/2018 12:11 PM, Paul Fultz II via cmake-developers wrote:
> https://github.com/pkgconf/pkgconf
> 
> CMake could use pkgconf internally

The license looks MIT-like.

Please confirm that it is at least BSD-3 compatible.

> find_package(zlib CONF)
> 
> And this would look up zlib using pkgconfig

An important distinction is that `find_package` is meant for whole
packages that may contain multiple libraries and components, while
IIUC a `.pc` file is equivalent to a single CMake target.  We'll
need a way to reconcile that.  Does pkgconfig have conventions for
meta-packages that cover multiple components?

Also, how should version matching work?

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] cmake on AIX

[Brad King]

On 06/12/2018 09:36 AM, REIX, Tony wrote:
> I never saw any package built on AIX using pthread or ppc64/pthread
> We have to understand why cmake is different.

We use C++11 std::thread.  It requires GCC's -pthread flag on AIX,
and that flag changes the standard library that is used.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] cmake on AIX

[Brad King]

On 06/12/2018 03:38 AM, REIX, Tony wrote:
> Did you use cmake built on AIX for building a project with it?
> cmake tests are 98% OK here though that does not work with mariaDB.

The test suite passes and that is mostly made up of project-like tests.
It's also built using an existing CMake/CTest on the machine (3.11).

> Thanks for the idea with static C++ runtime library!

I think that should solve any problems with running CMake in environments
different than it was built.

> Would you mind run the commands:
>dump -Hv cmake
>ldd cmake
> on the cmake command that you build, so that we can see which LIBPATH is set 
> into the executable.

The LIBPATH is

  
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0/pthread:/opt/freeware/lib/pthread:/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0:/opt/freeware/lib:/usr/lib:/lib

ldd shows for the C++ and C runtime libraries:

  
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0/pthread/libstdc++.a(libstdc++.so.6)
  /opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0/pthread/libgcc_s.a(shr.o)

> Did you build it by hand or with a script or a .spec file or anything that we 
> could look at?

It's build nightly by an existing CTest on the machine.  One of the
tests is the BootstrapTest which verifies that `./bootstrap` works.

> Looking at your build farm: 
> https://open.cdash.org/index.php?project=CMake=2018-06-12 , I see no AIX 
> machine.

That view is paged.  One can use filters to see just the AIX builds:

  
https://open.cdash.org/index.php?project=CMake=1=1=buildname=63=AIX

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] cmake on AIX

[Brad King]

On 06/11/2018 11:16 AM, REIX, Tony wrote:
> We are building cmake now only with GCC (6.3.0 for now) on AIX 6.1 .
> Which GCC compiler version are you using on AIX ?

GCC 7.2.  We previously tested with 6.1 and that worked too.

> It appears that the cmake executable has been built so that it looks for:
> libstdc++.a(libstdc++.so.6) in
>   
> /opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/6.3.0/pthread:/opt/freeware/lib/pthread/
> first, before the base /opt/freeware/lib. However, when we use it for building
> mariadb, we have to set the LIBPATH to: /opt/freeware/lib64:/usr/lib

Try switching to a static C++ runtime library:

  ./bootstrap -- -DCMAKE_EXE_LINKER_FLAGS='-static-libstdc++ -static-libgcc 
-Wl,-bbigtoc'

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] cmake on AIX

[Brad King]

On 06/08/2018 11:56 AM, REIX, Tony wrote:
> We'd like to know if cmake has already been ported on AIX.

Yes, it has long worked on AIX.  We have nightly testing
on AIX 7.2 with both GCC 7.2 and XL 13.1.  A couple of tests
are disabled for those builds but it works in general.

Since CMake 3.10 we require C++11 language and standard
library features so we've only gotten it compiling on AIX
using GCC.  The above-mentioned nightly builds still run
the test suite against XL too though.

If you're interested in running nightly testing too, more
machines/versions would be helpful.  See here:

  https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/testing.rst

You'd need to start with a GCC build.  Then I can help you
configure it to run the test suite with XL too.

> Version 3.11.1 :
>  # /opt/freeware/bin/cmake
> Could not load program /opt/freeware/bin/cmake:
> rtld: 0712-001 Symbol _ZTINSt6thread6_StateE was referenced
>   from module cmake(), but a runtime definition
>     of the symbol was not found.

How did you build or install it?

That symbol demangles to "typeinfo for std::thread::_State",
which is part of the C++ standard library.

Make sure the `libstdc++` library used at runtime is at
least as new as the one used when it was compiled.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Retrieving OS Version in CMake

[Brad King]

On 06/05/2018 11:24 AM, Harry Mallon wrote:
> Or is it best to add new fields?

We should only add new fields and revise documentation to match
existing behavior.

> e.g. one of the below?
> * OS_NAME: "Linux" -> "Fedora", OS_RELEASE: "$(uname -r)" -> "28"
> * OS_RELEASE: "$(uname -r)" -> "Fedora  28"
> * LINUX_DISTRO: "Fedora 28"

A separate LINUX_DISTRO sounds good, but we'd need to make sure
whatever convention is used for the version (in the name or as
a separate value) makes sense for all distros' conventions.

-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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Retrieving OS Version in CMake

[Brad King]

On 06/04/2018 01:41 PM, Harry Mallon wrote:
> Would there be a use case for a Module that could retrieve
> OS name and version

We do have these variables:

  https://cmake.org/cmake/help/v3.11/variable/CMAKE_HOST_SYSTEM_NAME.html
  https://cmake.org/cmake/help/v3.11/variable/CMAKE_HOST_SYSTEM_VERSION.html

and this command:

  https://cmake.org/cmake/help/v3.11/command/cmake_host_system_information.html

but...

> (e.g. on macOS parse “sw_vers” to get “Mac OS X” and “10.13.4”, on Linux
> parse /etc/os-release to get “Fedora” and “28”)?

...they don't go down to this level of detail.  Perhaps the

  cmake_host_system_information

command could be taught additional queries for that.

-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:
https://cmake.org/mailman/listinfo/cmake-developers