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

[Alexander]

Thank you very much, Brad. I found that WINDOWS_EXPORT_ALL_SYMBOLS was set
in my CMakeLists.txt.
After I removed it the /DEF parameter from CMAKE_SHARED_LINKER_FLAGS
appeared in the linking command.

--
Best Regards,
Alexander


On Fri, 8 Nov 2019 at 14:52, Brad King  wrote:

> 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

[Alexander]

I am sorry that I did not make it clear from the beginning. You are right.
Not only MSBuild, but MSVC linker (link.exe) accepts only one /DEF
parameter according to
https://docs.microsoft.com/en-us/cpp/build/reference/def-specify-module-definition-file?view=vs-2019
:
"""
The /DEF option passes a module-definition file (.def) to the linker. Only
one .def file can be specified to LINK.
"""
In reality you can pass multiple /DEF to the linker, but it uses the last
one.

The problem is that the original /DEF parameter
/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).
I wanted to override this parameter with a custom /DEF parameter, that
means my /DEF parameter must be passed after that default one in the
linking command.
However, as you can see from the linking command in my previous e-mail, I
could not easily achieve this with the current CMake functionality, because:
 - CMAKE_CXX_STANDARD_LIBRARIES adds custom /DEF parameter before the
default /DEF:exports.def that does not help
 - CMAKE_SHARED_LINKER_FLAGS adds something to the end of the command, but
only if this something is not /DEF (because one /DEF is already defined and
CMake does not overwrite it, as you said earlier)

So, does CMake provide a way to override the value of the default
/DEF:exports.def or does it provide a way to pass my custom
/DEF after the default one so that link.exe would use my custom /DEF
parameter?

--
Best Regards,
Alexander


On Tue, 5 Nov 2019 at 17:57, Brad King  wrote:

> 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] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

[Alexander]

Well, I have tested this proposal as well and I can confirm that it does
not work for me. I have added this code to my CMakeLists.txt:

string(APPEND CMAKE_SHARED_LINKER_FLAGS " -DEF:\"foo_1.def\"
-DEF111:\"foo_1.def\"")
string(APPEND CMAKE_CXX_STANDARD_LIBRARIES " -DEF:\"foo_2.def\"") # just in
order to illustrate that CMAKE_CXX_STANDARD_LIBRARIES works with DEF:
option in distinct to CMAKE_SHARED_LINKER_FLAGS

As a result I see "-DEF:foo_2.def" (in the middle of the linking command
right after the "standard" exports.def) and -DEF111:foo_1.def (at the and
of the linking command), however I don't see "-DEF:foo_1.def" and it means
it was stripped.
I am not sure that it can be informative, but for the illustration I show
the full linking command:

Link:
  C:\Program Files (x86)\Microsoft Visual
Studio\2017\WDExpress\VC\Tools\MSVC\14.16.27023\bin\HostX86\x64\link.exe
/ERRORREPORT:QUEUE
/OUT:"E:\workspace\cmake_test_option\tesseract\bin\bin\Release\tesseract41.dll"
/INCREMENTAL:NO /NOLOGO Ws2_32.lib
"E:\workspace\cmake_test_option\leptonica\bin\src\Release\leptonica-1.78.0.lib"
"e:\workspace\cmake_test_option\libjpeg\libjpeg_a.lib"
"e:\workspace\cmake_test_option\libpng\lib\libpng16_static.lib"
"e:\workspace\cmake_test_option\libtiff\lib\tiff.lib"
"e:\workspace\cmake_test_option\zlib\lib\zlibstatic.lib" kernel32.lib
user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib
uuid.lib comdlg32.lib advapi32.lib *"-DEF:foo_2.def"*
/DEF:"E:/workspace/cmake_test_option/tesseract/bin/libtesseract.dir/Release/exports.def"
/MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/manifest:embed
/PDB:"E:/workspace/cmake_test_option/tesseract/bin/bin/Release/tesseract41.pdb"
/SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT
/IMPLIB:"E:/workspace/cmake_test_option/tesseract/bin/Release/tesseract41.lib"
/MACHINE:X64  /machine:x64 *-DEF111:foo_1.def* /DLL
libtesseract.dir\Release\libtesseract.res


It proves what I wanted to say that CMAKE_SHARED_LINKER_FLAGS strips -DEF:
option in purpose, in distinct to CMAKE_CXX_STANDARD_LIBRARIES which
accepts everything.
For me it looks like a bug or like an undocumented behavior of
CMAKE_SHARED_LINKER_FLAGS.

--
Best Regards,
Alexander


On Thu, 10 Oct 2019 at 00:29, Brad King  wrote:

> 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

[Alexander]

In some cases it is not convenient to program something in CMakeFile.txt
(for example when I clone some 3rd party project and want to change its
build procedure).
Thus the possibility to add additional .defs files with the help of *command
line* options would be very nice. Such a command line option exists:
-DMAKE_SHARED_LINKER_FLAGS, but it deliberately ignores /DEF: which makes
impossible to add /DEF: this easy (and for me preferable) way.

I would like to get an answer from CMake developers, if it is an expected
behavior of  MAKE_SHARED_LINKER_FLAGS.
If yes: what is the logic behind it and why this special handling of
MAKE_SHARED_LINKER_FLAGS is not documented on
https://cmake.org/cmake/help/v3.15/variable/CMAKE_SHARED_LINKER_FLAGS.html.
If no: issue a bug.

--
Best Regards,
Alexander

Do it mean that

On Tue, 8 Oct 2019 at 16:57, Brad King  wrote:

> 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

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

[Alexander]

Dear CMake Developers,

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.

I already asked in the users-thread, but nobody could answer me directly if
it is bug or not. Original message:
https://cmake.org/pipermail/cmake/2019-October/070031.html.

--
Best Regards,
Alexander Samoilov
Build & Integration Engineer
Compart AG, 71034 Böblingen Germany
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[Alexander Neundorf]

On 2019 M03 20, Wed 13:53:49 CET Brad King via cmake-developers wrote:
> 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.

so this is now preferred over the server-mode ?

Alex



-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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: [CMake] link only with targets feature

[Alexander Neundorf]

On 2019 M02 12, Tue 08:34:57 CET Timothy Wrona wrote:
> I saw this email come through the cmake users mailing list but feel it is
> more fitting for it to go to cmake-developers so I'm forwarding it here.
> 
> It is a pretty long rant, but I think his idea to add a keyword to the
> "target_link_libraries()" command that would only look for cmake targets is
> a pretty great idea. I dont think it would break backwards compatibility
> either.
> 
> For example:
> 
> target_link_libraries(mytarget
>   LINK_TARGETS
> target1
> target1
> )
> 
> This would only search for CMake targets to link to and would not search
> for libraries with the same name. It would make adding alias namespace to
> targets not necessary anymore and would potentially make a lot of code look
> cleaner.

(I already replied on the cmake-list before I saw this here).
I would prefer if this could be combined with the include-directories via 
linking feature.
E.g. a command target_link_targets() which accepts only targets, and which has 
the include-directories features, and a policy to disable the include-
directories via target_link_libraries().

Alex

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 Cache Library

[Alexander Neundorf]

On 2018 M11 12, Mon 17:53:38 CET Taylor Holberton wrote:
> Hello everyone!
> 
> Today I released a short and sweet C++ library for accessing and modifying
> CMake Cache files.
> 
> Feel free to use it, critique it, or ignore it entirely.
> 
> You can find it on GitHub, at https://github.com/tay10r/cmake-cache
> 
> Thanks!

did you really choose GPLv3 as license for this ?

Alex

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] How to handle dependencies of protobuf files ?

[Alexander Neundorf]

Hi,

On 2018 M05 29, Tue 09:52:16 CEST Brad King wrote:
> On 05/15/2018 03:45 PM, Alexander Neundorf wrote:
> > I think to do it properly, there would have to be a dependency scanning
> > for
> > proto files like there is for C/C++ headers.
> 
> In order to handle implicit dependencies like that implied by
> 
> import "MyBase.proto";
> 
> then they would somehow need to be extracted from source content.
> Ideally protoc should be able to write a depfile as a side effect.
 
Parsing them using cmake would more or less work, also the include dirs are 
known, so technically this would probably work. But the parsing would happen 
at cmake-time, not at compile-time, but editing a proto-file does not trigger a 
cmake run...
Would that have to be implemented similar to the C dependency scanning ?

> Otherwise all dependencies should be listed explicitly somewhere.

so the cheap solution would be to add an argument to PROTOBUF_GENERATE_CPP() 
to list proto-files these proto-files depend on which is forwarded to (every) 
add_custom_command() call inside PROTOBUF_GENERATE_CPP().

Not very elegant, but at least it would make it work correctly.

This would require that if in a set of proto-files there are different 
dependencies, for each of those with different dependencies a separate 
PROTOBUF_GENERATE_CPP() would be needed.
A bit ugly, but better than now.

Alex

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] How to handle dependencies of protobuf files ?

[Alexander Neundorf]

Any comments ?

Alex

On 2018 M05 15, Tue 21:45:06 CEST Alexander Neundorf wrote:
> Hi,
> 
> I stumbled upon a problem with protobuf files, I attached a testcase.
> There is a MyBase.proto, which is "imported" by Complex.proto.
> If MyBase.proto is modified, protoc is run again in MyBase.proto, but not on
> Complex.proto, although it should.
> You can have a look at the attached example.
> 
> The message MyData (in Complex.proto) has a member MyBase b1.
> If I rename the message MyBase (in MyBase.proto) e.g. to MyBaseXYZ, then the
> build fails, because Complex.pb.h was not regenerated, so it still refered
> to the now not existing class MyBase.
> 
> Is there already a solution to handle this ?
> 
> I think to do it properly, there would have to be a dependency scanning for
> proto files like there is for C/C++ headers.
> Parsing at the proto-files at cmake time wouldn't be good enough (since
> editing a proto file doesn't trigger a cmake run).
> 
> Comments ?
> 
> Alex


-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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

[cmake-developers] How to handle dependencies of protobuf files ?

[Alexander Neundorf]

Hi,

I stumbled upon a problem with protobuf files, I attached a testcase.
There is a MyBase.proto, which is "imported" by Complex.proto.
If MyBase.proto is modified, protoc is run again in MyBase.proto, but not on 
Complex.proto, although it should.
You can have a look at the attached example.

The message MyData (in Complex.proto) has a member MyBase b1.
If I rename the message MyBase (in MyBase.proto) e.g. to MyBaseXYZ, then the 
build fails, because Complex.pb.h was not regenerated, so it still refered to 
the now not existing class MyBase.

Is there already a solution to handle this ?

I think to do it properly, there would have to be a dependency scanning for 
proto files like there is for C/C++ headers.
Parsing at the proto-files at cmake time wouldn't be good enough (since editing 
a proto file doesn't trigger a cmake run).

Comments ?

Alex


protodeps.tar.gz
Description: application/compressed-tar
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] new generator question - xml file output for embedded IDE platforms.

[Alexander Neundorf]

On 2018 M05 2, Wed 09:17:53 CEST du...@duaneellis.com wrote:
> >> configure_file is not the right command
> 
> Yea, it's the nearest existing item, and it only does the most
> simplistic replacement that's why I use that as a basis for my example.
> It is in effect, like the final last 'sed' step done by gnu
> autoconfigure tools. Nothing more.
> 
> >> If an IDE is actually not supported by CMake a generator it will have to
> >> be implemented for that in the source code of CMake.
> yea, i'm trying to avoid that - but I can write that if required :-(

I think you'll have to do this.

> 
> It's more then the IDE, it is also the CHIP effectively the SYSTEM
> 
> What I need is the variable data that Cmake has already and I need to be
> able to tell CMake that it *cannot* run the compiler instead, all of the
> information about the compiler will be provided via some Cmake script,
> for example names like this, either on the command line or specified in
> a Cmake file that holds alot of variables.
> 
>Cmake-Embedded-${CompilerName}.txt
>Cmake-Embedded-${ChipName}.txt
> 
> Possibly:
> 
>Cmake-Embedded-${RtosName}.txt
> 
> or
> 
>Cmake-Embedded-BareMetal.txt

this exists basically.
The files cmake loads are named --.cmake.
In CMake there are e.g. Generic-SDCC-C.cmake.
This would be "BareMetal" using sdcc.
You can write your own files for your own platforms.
OS and other settings can be set up in your toolchain file.

Are you familiar with cmake cross-compiling support in CMake ?
If not, please get into this, it handles many of the issues you have.

Alex

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Adding a non-make based generator

[Alexander Neundorf]

Hi,

On 2018 M02 14, Wed 22:16:54 CEST Alexander Neundorf wrote:
> On 2018 M02 14, Wed 18:46:52 CET Saeed, Khurram wrote:
> > Thanks Alex.
> > Yes it does support generating the project in the build dir. It also works
> > while generating in a subdir of the source dir. Eclipse version control
> > plugin also works (I am using git).
> 
> Interesting.
> How did you get that working ?
> 
> Let's say the directories look like this:
> 
> src/CMakeLists.txt
> build/CMakeCache.txt
> build/.project
> build/.cproject
> 
> I guess this is what you generate, right ?
> How do you get the source tree into this project ?
> The Eclipse-generator in cmake uses a "linked resource" to the source dir,
> but the version control plugin is not activated for those files.
> According to the Subversion-Plugin developers this is because the source
> files are then outside the "project directory", i.e. no below the directory
> where the .project file is located.
> 
> So I'm really interested how you got that working.
> Can you send the .project and .cproject files for a simple hello-world
> project, built out-of-source ?

any news here ?

Alex

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Adding a non-make based generator

[Alexander Neundorf]

On 2018 M02 14, Wed 18:46:52 CET Saeed, Khurram wrote:
> Thanks Alex.
> Yes it does support generating the project in the build dir. It also works
> while generating in a subdir of the source dir. Eclipse version control
> plugin also works (I am using git).

Interesting.
How did you get that working ?

Let's say the directories look like this:

src/CMakeLists.txt
build/CMakeCache.txt
build/.project
build/.cproject

I guess this is what you generate, right ?
How do you get the source tree into this project ?
The Eclipse-generator in cmake uses a "linked resource" to the source dir, but 
the version control plugin is not activated for those files.
According to the Subversion-Plugin developers this is because the source files 
are then outside the "project directory", i.e. no below the directory where 
the .project file is located.

So I'm really interested how you got that working.
Can you send the .project and .cproject files for a simple hello-world project, 
built out-of-source ?

Alex

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Adding a non-make based generator

[Alexander Neundorf]

Hi,

On 2018 M02 9, Fri 13:16:19 CET Saeed, Khurram wrote:
> Hi Alex,
> 
> I have not made it available anywhere so far. Although my target while
> writing this generator was only to make it work for ReadyStart projects.
> However, I think with some effort down the road it might be possible to use
> it for normal Eclipse CDT projects as well.
> 
> We want to make it available to general public but we have been wondering
> whether or not it would be "acceptable" to have a generator that generates
> managed Eclipse CDT projects?

well, Brad is the maintainer.
I think in general a "real" Eclipse CDT project generator would be preferred 
over the existing one which generates a makefile-based project for Eclipse.

I could try to support you a bit.

Does it support generating the project in the build dir, i.e. outside the 
source dir (or in a subdir of the source dir), and does then the Eclipse 
version control plugin (svn/git) work ?

Alex

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Adding a non-make based generator

[Alexander Neundorf]

Hi Kurram,

On 2018 M02 7, Wed 12:09:54 CET Saeed, Khurram wrote:
> Hi Neundorf,
> This generator can only be used for generating Nucleus ReadyStart IDE
> projects. It generates Eclipse CDT project files that use ReadyStart
> specific plugins and configurations.

I have the impression Brad was not overly excited.
On the other I have the impression that the Eclipse CDT team is also not 
overly excited of the cmake server mode (at least 2 years ago when I was on 
the mailing list).

Would it be hard to extend your generator so that it can also be used for 
"normal" Eclipse CDT projects ? Is it already available somewhere, e.g. github 
?

Alex

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Adding a non-make based generator

[Alexander Neundorf]

Hi Saeed,

On 2018 M02 2, Fri 15:05:19 CET Saeed, Khurram wrote:
> Hi,
> Nucleus
> ReadyStart is
> an eclipse based IDE by Mentor Embedded(tm).
> It is used for creating and building C/C++ based Nucleus
> RTOS projects for
> embedded devices. We have added a new generator in CMake to give the option
> of generating Nucleus ReadyStart based projects to our customers. This is
> not a 'make-based' generator as Nucleus ReadyStart projects are built using
> Eclipse CDT managed build system. In this generator we are generating
> .project and .cproject files for Nucleus ReadyStart application.
> 
> Do you think we can contribute this generator to community?

does that mean it also works for "normal" Eclipse CDT, or only for ReadyStart 
?
If it works for Eclipse in general, I would happily remove the current Eclipse 
CDT generator (which I wrote).
Do all tests pass using your generator ?

Alex

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] kwsysProcess threadsafety

[Alexander Neundorf]

On 2018 M01 8, Mon 10:32:22 CET Jean-Michaël Celerier wrote:
> > 3) Abandon the idea to parallelize AUTOMOC/UIC
> 
> please no ! moc is a huge bottleneck in my builds (to the point that using
> verdigris  instead ends up having
> faster build time overall).

you could also just not use automoc and use the "manual" moc-wrapper macros. 
This should make the build-time overhead go away.
Instead the developer has to add the header file to be moc'ed to the 
CMakeLists.txt (personally I consider this acceptable).

Alex

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Antwort: Re: Non supported toolchain

[Alexander Neundorf]

On 2017 M11 23, Thu 07:22:19 CET oliver.za...@egoproducts.com wrote:
> Hi Alex,
> 
> thanks for your answer.
> 1. is there some guide or at least some example?
> 2. Does this module needs to be in the offical build to be distributed or
> is there a possibility to distribute the modules locally?

you could have a look e.g. at Modules/Compiler/TI*.cmake, or the IAR files.

You can try whether you can have your custom files in some directory and adjust 
CMAKE_MODULE_PATH accordingly. I'm not sure, but it might work.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Non supported toolchain

[Alexander Neundorf]

On 2017 M11 22, Wed 10:37:00 CET oliver.za...@egoproducts.com wrote:
> Hi,
> 
> i know this is the dev mailing list, but i tried to solve my problem in
> the normal one (see here
> https://www.mail-archive.com/cmake@cmake.org/msg57862.html) with no
> success.
> 
> In Short: i have a toolchain for an microcontroller (renesas rx serjes)
> running on windows. I want to build my project with cmake and therefor
> wrote a toolchain file.
> The problem now is, that the compiler needs instead of "-I" for includes
> "-include=" and for defines "-define=". I found out that there seems to be
> internal variables CMAKE_INCLUDE_FLAG_C and CMAKE_DEFINE_FLAC_C but they
> don't seem to accesible from the toolchain file.
> 
> Is there any chance beside writing a new module for a compiler to get this
> toolchain running?

no, you probably need to write a module file for the compiler. This is actually 
not that complicated.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Native Compilers

[Alexander Neundorf]

On 2017 M09 26, Tue 16:21:21 CEST Kevin Funk wrote:
> On Monday, 25 September 2017 20:39:01 CEST Ivam Pretti wrote:
> > When you use cmake-gui, below the button configure  there is an option to
> > choose the compiler. This compilers are alredy intalled with cmake or it
> > needs to install separetely?
> > 
> > Another question, when you specify a for example kdevelop files is it
> > necessary to run at kdevelop to get the executables files?
> 
> Heya,
> 
> Not sure if you took KDevelop just as an example, but let me clarify that
> the generator for the KDevelop project files is unmaintained (to my
> knowledge). [1]

yes, it's actually for KDevelop 3.
Maybe it should be removed ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [PATCH 1/1] Add binutils' size to list of variables

[Alexander Stein]

In case there is no native size tool (e.g. on Windows) a binutils
toolchain provides this. Create a variable for it.

Signed-off-by: Alexander Stein 
---
 Modules/CMakeFindBinUtils.cmake | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Modules/CMakeFindBinUtils.cmake b/Modules/CMakeFindBinUtils.cmake
index e4103d0b7c..3c41498874 100644
--- a/Modules/CMakeFindBinUtils.cmake
+++ b/Modules/CMakeFindBinUtils.cmake
@@ -57,8 +57,9 @@ else()
   find_program(CMAKE_NM NAMES ${_CMAKE_TOOLCHAIN_PREFIX}nm HINTS 
${_CMAKE_TOOLCHAIN_LOCATION})
   find_program(CMAKE_OBJDUMP NAMES ${_CMAKE_TOOLCHAIN_PREFIX}objdump HINTS 
${_CMAKE_TOOLCHAIN_LOCATION})
   find_program(CMAKE_OBJCOPY NAMES ${_CMAKE_TOOLCHAIN_PREFIX}objcopy HINTS 
${_CMAKE_TOOLCHAIN_LOCATION})
+  find_program(CMAKE_SIZE NAMES ${_CMAKE_TOOLCHAIN_PREFIX}size HINTS 
${_CMAKE_TOOLCHAIN_LOCATION})
 
-  mark_as_advanced(CMAKE_AR CMAKE_RANLIB CMAKE_STRIP CMAKE_LINKER CMAKE_NM 
CMAKE_OBJDUMP CMAKE_OBJCOPY)
+  mark_as_advanced(CMAKE_AR CMAKE_RANLIB CMAKE_STRIP CMAKE_LINKER CMAKE_NM 
CMAKE_OBJDUMP CMAKE_OBJCOPY CMAKE_SIZE)
 
 endif()
 
-- 
2.13.0

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Feature suggestion: auto-create missing files

[Alexander Neundorf]

On 2017 M04 11, Tue 11:52:52 CEST Brad King wrote:
> On 04/11/2017 11:41 AM, Petr Kmoch wrote:
> > Currently, adding a new source file to a CMake-controlled project
> > means doing two things: creating the file on disk, and adding it
> > to the relevant CMakeList add_library() or add_executable() call.
> 
> I view this as a matching pair with an implicit sanity check.
> 
> > switch from current behaviour of "error out if source file is not found"
> > to "create empty source file if it's not found."
> 
> So a typo in the `CMakeLists.txt` file leads to silent creation of a
> source file instead of an error message?
> 
> That said, I can see how the proposed feature might be useful when
> iteratively developing in an IDE.  Add the file to `CMakeLists.txt`,
> reconfigure, and open the new (now existing) file to edit in the IDE.
> 
> > Is this something that would be acceptable into CMake? Any comments?
> 
> I'd like to hear more opinions from others before considering it
> upstream.  It feels like a pretty personal workflow right now, and
> can be implemented in CMake code already (perhaps with the `SOURCES`
> target property to avoid separate lists).

personally I'm not convinced.
Technically it would violate the "the source dir is read-only" rule.
A typo would generate files. With multiple build dirs the behaviour will be 
slightly different in the two dirs.
...not very strong arguments, but OTOH touching the file manually is also not 
too complicated.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Eclipse CDT Managed build

[Alexander Neundorf]

On 2017 M01 25, Wed 11:38:06 CET Brad King wrote:
> On 01/25/2017 11:27 AM, Ben Boeckel wrote:
> > not be trivial to get CMake to generate relocatable builds.
> 
> This is also an explicit non-goal of CMake.
> 
> >> after CMake generation the project can be configured through the IDE UI.
> 
> That is likely not compatible with CMake's notion of maintaining
> the build system.
> 
> This is why previous similar discussions resulted in the cmake server
> mode and in identifying the value of a declarative spec format that
> can be managed outside of CMake's language processor.

IOW, now that cmake has server-mode, the recommended approach is to implement 
a plugin for cmake-server mode in Eclipse.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [Discussion] Down with discrimination CPack!

[Alexander Neundorf]

On 2017 M01 18, Wed 22:20:14 CET Konstantin Podsvirov wrote:
> What about add to CMake language new packaging problematic scopes:
> 
> - COMPONENT;
> - COMPONENT_GROUP;
> - PACKAGE;
> - INSTALLER;
> - REPOSITORY?

that's a quite terse proposal...

Alex


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] (Re-)Added RPM Suggested Dependency Support

[Alexander Adam]

On Freitag, 4. November 2016 09:34:46 CET you wrote:

> Would you be willing to also write a test for the SUGGESTS tag?
> The tests are located in Tests/RunCMake/CPack, you add the test to
> RunCMakeTest.cmake and for an example of a test similar to what you'd need
> to write you can search the CPack directory for all files containing
> PER_COMPONENT_FIELDS in their name.

I took the LONG_FILENAME test for deb packages as a template for the following 
patch. Is it more or less what you had in mind?

Alexanderdiff --git a/Tests/RunCMake/CPack/RPM/RPM_SUGGESTS-ExpectedFiles.cmake b/Tests/RunCMake/CPack/RPM/RPM_SUGGESTS-ExpectedFiles.cmake
new file mode 100644
index 000..e714884
--- /dev/null
+++ b/Tests/RunCMake/CPack/RPM/RPM_SUGGESTS-ExpectedFiles.cmake
@@ -0,0 +1,5 @@
+set(whitespaces_ "[\t\n\r ]*")
+
+set(EXPECTED_FILES_COUNT "1")
+set(EXPECTED_FILE_1 "suggested*.rpm")
+set(EXPECTED_FILE_CONTENT_1 "^.*/usr/${whitespaces_}.*/usr/foo/${whitespaces_}.*/usr/foo/suggested.txt$")
diff --git a/Tests/RunCMake/CPack/RPM/RPM_SUGGESTS-Prerequirements.cmake b/Tests/RunCMake/CPack/RPM/RPM_SUGGESTS-Prerequirements.cmake
new file mode 100644
index 000..af4285d
--- /dev/null
+++ b/Tests/RunCMake/CPack/RPM/RPM_SUGGESTS-Prerequirements.cmake
@@ -0,0 +1,21 @@
+function(get_test_prerequirements found_var)
+  find_program(RPMBUILD_EXECUTABLE NAMES rpmbuild)
+  find_program(RPM_EXECUTABLE NAMES rpm)
+
+  if(RPMBUILD_EXECUTABLE AND RPM_EXECUTABLE)
+execute_process(COMMAND ${RPMBUILD_EXECUTABLE} --querytags
+OUTPUT_VARIABLE RPMBUILD_CAPS
+RESULT_VARIABLE RPMBUILD_CAPS_RESULT)
+
+if(RPMBUILD_CAPS_RESULT)
+  string(REPLACE "\n" " " RPMBUILD_CAPS_LINE ${RPMBUILD_CAPS})
+  set(RPMBUILD_CAPS_LINE " ${RPMBUILD_CAPS_LINE}")
+
+  string(FIND "${RPMBUILD_CAPS_LINE}" " SUGGESTS " RPMBUILD_HAS_SUGGESTS)
+
+  if(RPMBUILD_HAS_SUGGESTS)
+set(${found_var} true PARENT_SCOPE)
+  endif()
+endif()
+  endif()
+endfunction()
diff --git a/Tests/RunCMake/CPack/RPM/RPM_SUGGESTS-VerifyResult.cmake b/Tests/RunCMake/CPack/RPM/RPM_SUGGESTS-VerifyResult.cmake
new file mode 100644
index 000..046e2d3
--- /dev/null
+++ b/Tests/RunCMake/CPack/RPM/RPM_SUGGESTS-VerifyResult.cmake
@@ -0,0 +1,10 @@
+execute_process(COMMAND ${RPM_EXECUTABLE} -q --suggests -p ${FOUND_FILE_1}
+RESULT_VARIABLE rpm_result_
+OUTPUT_VARIABLE rpm_output_
+OUTPUT_QUIET)
+
+string(FIND "${rpm_output_}" "suggested" HAS_SUGGESTED)
+
+if(NOT (rpm_result_ AND HAS_SUGGESTED))
+  message(FATAL_ERROR "RPM_SUGGESTED package error: no suggested packages"
+endif()
diff --git a/Tests/RunCMake/CPack/RPM_SUGGESTS.cmake b/Tests/RunCMake/CPack/RPM_SUGGESTS.cmake
new file mode 100644
index 000..1dd7e29
--- /dev/null
+++ b/Tests/RunCMake/CPack/RPM_SUGGESTS.cmake
@@ -0,0 +1,11 @@
+set(FILENAME
+  "${CMAKE_CURRENT_BINARY_DIR}/suggests_test.txt")
+
+file(WRITE
+  "${LONG_FILENAME}"
+  "suggests_test")
+
+install(FILES ${FILENAME} DESTINATION foo)
+
+set(CPACK_RPM_PACKAGE_SUGGESTS "libsuggested")
+set(CPACK_PACKAGE_NAME "suggested")
diff --git a/Tests/RunCMake/CPack/RunCMakeTest.cmake b/Tests/RunCMake/CPack/RunCMakeTest.cmake
index 474ee33..38bd0ea 100644
--- a/Tests/RunCMake/CPack/RunCMakeTest.cmake
+++ b/Tests/RunCMake/CPack/RunCMakeTest.cmake
@@ -15,6 +15,7 @@ run_cpack_test(CUSTOM_NAMES "RPM;DEB" true)
 run_cpack_test_subtests(MAIN_COMPONENT "invalid;found" "RPM" false)
 run_cpack_test(PER_COMPONENT_FIELDS "RPM;DEB" false)
 run_cpack_test(RPM_DIST "RPM" false)
+run_cpack_test(RPM_SUGGESTS "RPM" false)
 run_cpack_test(INSTALL_SCRIPTS "RPM" false)
 run_cpack_test(DEB_GENERATE_SHLIBS "DEB" true)
 run_cpack_test(DEB_GENERATE_SHLIBS_LDCONFIG "DEB" true)
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] (Re-)Added RPM Suggested Dependency Support

[Alexander Adam]

Hello,

after searching how to use the documented 
CPACK_RPM__PACKAGE_SUGGESTS feature, I stumbled across the 
following ticket: https://gitlab.kitware.com/cmake/cmake/issues/13423

After reading through the discussion, I tried to fix the remaining issues and 
came up with the attached patch (against master). I also added the patched 
CPackRPM.cmake for security.

Alexander# Distributed under the OSI-approved BSD 3-Clause License.  See accompanying
# file Copyright.txt or https://cmake.org/licensing for details.

#.rst:
# CPackRPM
# 
#
# The built in (binary) CPack RPM generator (Unix only)
#
# Variables specific to CPack RPM generator
# ^
#
# CPackRPM may be used to create RPM packages using :module:`CPack`.
# CPackRPM is a :module:`CPack` generator thus it uses the ``CPACK_XXX``
# variables used by :module:`CPack`.
#
# CPackRPM has specific features which are controlled by the specifics
# :code:`CPACK_RPM_XXX` variables.
#
# :code:`CPACK_RPM__` variables may be used in order to have
# **component** specific values.  Note however that  refers to the
# **grouping name** written in upper case. It may be either a component name or
# a component GROUP name. Usually those variables correspond to RPM spec file
# entities. One may find information about spec files here
# http://www.rpm.org/wiki/Docs
#
# .. note::
#
#  `` part of variables is preferred to be in upper case (for e.g. if
#  component is named `foo` then use `CPACK_RPM_FOO_` variable name format)
#  as is with other `CPACK__` variables.
#  For the purposes of back compatibility (CMake/CPack version 3.5 and lower)
#  support for same cased component (e.g. `fOo` would be used as
#  `CPACK_RPM_fOo_`) is still supported for variables defined in older
#  versions of CMake/CPack but is not guaranteed for variables that
#  will be added in the future. For the sake of back compatibility same cased
#  component variables also override upper cased versions where both are
#  present.
#
# Here are some CPackRPM wiki resources that are here for historic reasons and
# are no longer maintained but may still prove useful:
#
#  - https://cmake.org/Wiki/CMake:CPackConfiguration
#  - https://cmake.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29
#
# List of CPackRPM specific variables:
#
# .. variable:: CPACK_RPM_PACKAGE_COMPONENT
#
#  Enable component packaging for CPackRPM
#
#  * Mandatory : NO
#  * Default   : OFF
#
#  If enabled (ON) multiple packages are generated. By default a single package
#  containing files of all components is generated.
#
# .. variable:: CPACK_RPM_PACKAGE_SUMMARY
#   CPACK_RPM__PACKAGE_SUMMARY
#
#  The RPM package summary.
#
#  * Mandatory : YES
#  * Default   : :variable:`CPACK_PACKAGE_DESCRIPTION_SUMMARY`
#
# .. variable:: CPACK_RPM_PACKAGE_NAME
#   CPACK_RPM__PACKAGE_NAME
#
#  The RPM package name.
#
#  * Mandatory : YES
#  * Default   : :variable:`CPACK_PACKAGE_NAME`
#
# .. variable:: CPACK_RPM_FILE_NAME
#   CPACK_RPM__FILE_NAME
#
#  Package file name.
#
#  * Mandatory : YES
#  * Default   : ``[-].rpm`` with spaces
#replaced by '-'
#
#  This may be set to ``RPM-DEFAULT`` to allow rpmbuild tool to generate package
#  file name by itself.
#  Alternatively provided package file name must end with ``.rpm`` suffix.
#
#  .. note::
#
#By using user provided spec file, rpm macro extensions such as for
#generating debuginfo packages or by simply using multiple components more
#than one rpm file may be generated, either from a single spec file or from
#multiple spec files (each component execution produces it's own spec file).
#In such cases duplicate file names may occur as a result of this variable
#setting or spec file content structure. Duplicate files get overwritten
#and it is up to the packager to set the variables in a manner that will
#prevent such errors.
#
# .. variable:: CPACK_RPM_PACKAGE_VERSION
#
#  The RPM package version.
#
#  * Mandatory : YES
#  * Default   : :variable:`CPACK_PACKAGE_VERSION`
#
# .. variable:: CPACK_RPM_PACKAGE_ARCHITECTURE
#   CPACK_RPM__PACKAGE_ARCHITECTURE
#
#  The RPM package architecture.
#
#  * Mandatory : YES
#  * Default   : Native architecture output by ``uname -m``
#
#  This may be set to ``noarch`` if you know you are building a noarch package.
#
# .. variable:: CPACK_RPM_PACKAGE_RELEASE
#
#  The RPM package release.
#
#  * Mandatory : YES
#  * Default   : 1
#
#  This is the numbering of the RPM package itself, i.e. the version of the
#  packaging and not the version of the content (see
#  :variable:`CPACK_RPM_PACKAGE_VERSION`). One may change the default value if
#  the previous packaging was buggy and/or you want to put here a fancy Linux
#  distro specific numbering.
#
# .. note::
#
#  This is the string that goes into the RPM ``Release:`` field. Some distros
#  (e.g. Fedora, CentOS) require ``1%{?dist}`` format

Re: [cmake-developers] FindOpenSSL: Link libraries needed for static OpenSSL.

[Alexander Lamaison]

On 15 August 2016 at 14:25, Brad King  wrote:
> On 08/14/2016 01:58 PM, Alexander Lamaison wrote:
>> This patch updates FindOpenSSL.cmake to include the necessary system
>> libs in the OpenSSL libraries variables and in the OpenSSL::Crypto and
>> OpenSSL::SSL target properties.
>
> Thanks.  The singluar-named OPENSSL_{SSL,CRYPTO}_LIBRARY variables
> are meant just to hold the specific library files (i.e. the result
> of one find_library call).  Instead of placing the dependencies
> directly in them we should have other (internal) variables to hold
> them.  That will also avoid duplicating conditions for filling in
> the imported target information.


I've attached a new patch without the changes to the singular-named variables.

Alex
From e6cca7701b9b04507ec9d1a054dcc6f3652b61bb Mon Sep 17 00:00:00 2001
From: Alexander Lamaison 
Date: Tue, 16 Aug 2016 21:23:57 +0100
Subject: [PATCH] FindOpenSSL: Link libraries needed for static OpenSSL.

OpenSSL depends on system libraries.  When linking statically again
OpenSSL, the client target must also link those libraries.

This patch updates FindOpenSSL.cmake to include the necessary system
libs in the OpenSSL libraries variables and in the OpenSSL::Crypto and
OpenSSL::SSL target properties.

The dependencies:
Windows: crypt32
Unix: CMAKE_DL_LIBS
---
 Modules/FindOpenSSL.cmake | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/Modules/FindOpenSSL.cmake b/Modules/FindOpenSSL.cmake
index 10b62ff..ac55416 100644
--- a/Modules/FindOpenSSL.cmake
+++ b/Modules/FindOpenSSL.cmake
@@ -201,7 +201,7 @@ if(WIN32 AND NOT CYGWIN)
  SSL_EAY_LIBRARY_DEBUG SSL_EAY_LIBRARY_RELEASE)
 set(OPENSSL_SSL_LIBRARY ${SSL_EAY_LIBRARY} )
 set(OPENSSL_CRYPTO_LIBRARY ${LIB_EAY_LIBRARY} )
-set(OPENSSL_LIBRARIES ${SSL_EAY_LIBRARY} ${LIB_EAY_LIBRARY} )
+set(OPENSSL_LIBRARIES ${SSL_EAY_LIBRARY} ${LIB_EAY_LIBRARY} crypt32)
   elseif(MINGW)
 # same player, for MinGW
 set(LIB_EAY_NAMES crypto libeay32)
@@ -229,7 +229,7 @@ if(WIN32 AND NOT CYGWIN)
 mark_as_advanced(SSL_EAY LIB_EAY)
 set(OPENSSL_SSL_LIBRARY ${SSL_EAY} )
 set(OPENSSL_CRYPTO_LIBRARY ${LIB_EAY} )
-set(OPENSSL_LIBRARIES ${SSL_EAY} ${LIB_EAY} )
+set(OPENSSL_LIBRARIES ${SSL_EAY} ${LIB_EAY} crypt32)
 unset(LIB_EAY_NAMES)
 unset(SSL_EAY_NAMES)
   else()
@@ -259,7 +259,7 @@ if(WIN32 AND NOT CYGWIN)
 mark_as_advanced(SSL_EAY LIB_EAY)
 set(OPENSSL_SSL_LIBRARY ${SSL_EAY} )
 set(OPENSSL_CRYPTO_LIBRARY ${LIB_EAY} )
-set(OPENSSL_LIBRARIES ${SSL_EAY} ${LIB_EAY} )
+set(OPENSSL_LIBRARIES ${SSL_EAY} ${LIB_EAY} crypt32)
   endif()
 else()
 
@@ -290,10 +290,10 @@ else()
   mark_as_advanced(OPENSSL_CRYPTO_LIBRARY OPENSSL_SSL_LIBRARY)
 
   # compat defines
-  set(OPENSSL_SSL_LIBRARIES ${OPENSSL_SSL_LIBRARY})
-  set(OPENSSL_CRYPTO_LIBRARIES ${OPENSSL_CRYPTO_LIBRARY})
+  set(OPENSSL_SSL_LIBRARIES ${OPENSSL_SSL_LIBRARY} ${CMAKE_DL_LIBS})
+  set(OPENSSL_CRYPTO_LIBRARIES ${OPENSSL_CRYPTO_LIBRARY} ${CMAKE_DL_LIBS})
 
-  set(OPENSSL_LIBRARIES ${OPENSSL_SSL_LIBRARY} ${OPENSSL_CRYPTO_LIBRARY})
+  set(OPENSSL_LIBRARIES ${OPENSSL_SSL_LIBRARY} ${OPENSSL_CRYPTO_LIBRARY} ${CMAKE_DL_LIBS})
 
 endif()
 
@@ -394,6 +394,13 @@ if(OPENSSL_FOUND)
 add_library(OpenSSL::Crypto UNKNOWN IMPORTED)
 set_target_properties(OpenSSL::Crypto PROPERTIES
   INTERFACE_INCLUDE_DIRECTORIES "${OPENSSL_INCLUDE_DIR}")
+if(WIN32 AND NOT CYGWIN)
+  set_target_properties(OpenSSL::Crypto PROPERTIES
+INTERFACE_LINK_LIBRARIES crypt32)
+else()
+  set_target_properties(OpenSSL::Crypto PROPERTIES
+INTERFACE_LINK_LIBRARIES "${CMAKE_DL_LIBS}")
+endif()
 if(EXISTS "${OPENSSL_CRYPTO_LIBRARY}")
   set_target_properties(OpenSSL::Crypto PROPERTIES
 IMPORTED_LINK_INTERFACE_LANGUAGES "C"
@@ -445,6 +452,12 @@ if(OPENSSL_FOUND)
   set_target_properties(OpenSSL::SSL PROPERTIES
 INTERFACE_LINK_LIBRARIES OpenSSL::Crypto)
 endif()
+if(WIN32 AND NOT CYGWIN)
+  set_property(TARGET OpenSSL::SSL APPEND PROPERTY
+	INTERFACE_LINK_LIBRARIES crypt32)
+else()
+  set_property(TARGET OpenSSL::SSL APPEND PROPERTY
+	INTERFACE_LINK_LIBRARIES "${CMAKE_DL_LIBS}")
   endif()
 endif()
 
-- 
2.9.2

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] FindOpenSSL: Link libraries needed for static OpenSSL.

[Alexander Lamaison]

OpenSSL depends on system libraries.  When linking statically again
OpenSSL, the client target must also link those libraries.

This patch updates FindOpenSSL.cmake to include the necessary system
libs in the OpenSSL libraries variables and in the OpenSSL::Crypto and
OpenSSL::SSL target properties.

The dependencies:
Windows: crypt32
Unix: CMAKE_DL_LIBS
From 4c1332675ad6b8bce360285869b90d4302735d5b Mon Sep 17 00:00:00 2001
From: Alexander Lamaison 
Date: Sun, 14 Aug 2016 18:45:46 +0100
Subject: [PATCH] FindOpenSSL: Link libraries needed for static OpenSSL.

OpenSSL depends on system libraries.  When linking statically again
OpenSSL, the client target must also link those libraries.

This patch updates FindOpenSSL.cmake to include the necessary system
libs in the OpenSSL libraries variables and in the OpenSSL::Crypto and
OpenSSL::SSL target properties.

The dependencies:
Windows: crypt32
Unix: CMAKE_DL_LIBS
---
 Modules/FindOpenSSL.cmake | 37 +
 1 file changed, 25 insertions(+), 12 deletions(-)

diff --git a/Modules/FindOpenSSL.cmake b/Modules/FindOpenSSL.cmake
index 10b62ff..275d283 100644
--- a/Modules/FindOpenSSL.cmake
+++ b/Modules/FindOpenSSL.cmake
@@ -199,9 +199,9 @@ if(WIN32 AND NOT CYGWIN)
 
 mark_as_advanced(LIB_EAY_LIBRARY_DEBUG LIB_EAY_LIBRARY_RELEASE
  SSL_EAY_LIBRARY_DEBUG SSL_EAY_LIBRARY_RELEASE)
-set(OPENSSL_SSL_LIBRARY ${SSL_EAY_LIBRARY} )
-set(OPENSSL_CRYPTO_LIBRARY ${LIB_EAY_LIBRARY} )
-set(OPENSSL_LIBRARIES ${SSL_EAY_LIBRARY} ${LIB_EAY_LIBRARY} )
+set(OPENSSL_SSL_LIBRARY ${SSL_EAY_LIBRARY} crypt32)
+set(OPENSSL_CRYPTO_LIBRARY ${LIB_EAY_LIBRARY} crypt32)
+set(OPENSSL_LIBRARIES ${SSL_EAY_LIBRARY} ${LIB_EAY_LIBRARY} crypt32)
   elseif(MINGW)
 # same player, for MinGW
 set(LIB_EAY_NAMES crypto libeay32)
@@ -227,9 +227,9 @@ if(WIN32 AND NOT CYGWIN)
 )
 
 mark_as_advanced(SSL_EAY LIB_EAY)
-set(OPENSSL_SSL_LIBRARY ${SSL_EAY} )
-set(OPENSSL_CRYPTO_LIBRARY ${LIB_EAY} )
-set(OPENSSL_LIBRARIES ${SSL_EAY} ${LIB_EAY} )
+set(OPENSSL_SSL_LIBRARY ${SSL_EAY} crypt32)
+set(OPENSSL_CRYPTO_LIBRARY ${LIB_EAY} crypt32)
+set(OPENSSL_LIBRARIES ${SSL_EAY} ${LIB_EAY} crypt32)
 unset(LIB_EAY_NAMES)
 unset(SSL_EAY_NAMES)
   else()
@@ -257,9 +257,9 @@ if(WIN32 AND NOT CYGWIN)
 )
 
 mark_as_advanced(SSL_EAY LIB_EAY)
-set(OPENSSL_SSL_LIBRARY ${SSL_EAY} )
-set(OPENSSL_CRYPTO_LIBRARY ${LIB_EAY} )
-set(OPENSSL_LIBRARIES ${SSL_EAY} ${LIB_EAY} )
+set(OPENSSL_SSL_LIBRARY ${SSL_EAY} crypt32)
+set(OPENSSL_CRYPTO_LIBRARY ${LIB_EAY} crypt32)
+set(OPENSSL_LIBRARIES ${SSL_EAY} ${LIB_EAY} crypt32)
   endif()
 else()
 
@@ -290,10 +290,10 @@ else()
   mark_as_advanced(OPENSSL_CRYPTO_LIBRARY OPENSSL_SSL_LIBRARY)
 
   # compat defines
-  set(OPENSSL_SSL_LIBRARIES ${OPENSSL_SSL_LIBRARY})
-  set(OPENSSL_CRYPTO_LIBRARIES ${OPENSSL_CRYPTO_LIBRARY})
+  set(OPENSSL_SSL_LIBRARIES ${OPENSSL_SSL_LIBRARY} ${CMAKE_DL_LIBS})
+  set(OPENSSL_CRYPTO_LIBRARIES ${OPENSSL_CRYPTO_LIBRARY} ${CMAKE_DL_LIBS})
 
-  set(OPENSSL_LIBRARIES ${OPENSSL_SSL_LIBRARY} ${OPENSSL_CRYPTO_LIBRARY})
+  set(OPENSSL_LIBRARIES ${OPENSSL_SSL_LIBRARY} ${OPENSSL_CRYPTO_LIBRARY} ${CMAKE_DL_LIBS})
 
 endif()
 
@@ -394,6 +394,13 @@ if(OPENSSL_FOUND)
 add_library(OpenSSL::Crypto UNKNOWN IMPORTED)
 set_target_properties(OpenSSL::Crypto PROPERTIES
   INTERFACE_INCLUDE_DIRECTORIES "${OPENSSL_INCLUDE_DIR}")
+if(WIN32 AND NOT CYGWIN)
+  set_target_properties(OpenSSL::Crypto PROPERTIES
+INTERFACE_LINK_LIBRARIES crypt32)
+else()
+  set_target_properties(OpenSSL::Crypto PROPERTIES
+INTERFACE_LINK_LIBRARIES "${CMAKE_DL_LIBS}")
+endif()
 if(EXISTS "${OPENSSL_CRYPTO_LIBRARY}")
   set_target_properties(OpenSSL::Crypto PROPERTIES
 IMPORTED_LINK_INTERFACE_LANGUAGES "C"
@@ -445,6 +452,12 @@ if(OPENSSL_FOUND)
   set_target_properties(OpenSSL::SSL PROPERTIES
 INTERFACE_LINK_LIBRARIES OpenSSL::Crypto)
 endif()
+if(WIN32 AND NOT CYGWIN)
+  set_property(TARGET OpenSSL::SSL APPEND PROPERTY
+	INTERFACE_LINK_LIBRARIES crypt32)
+else()
+  set_property(TARGET OpenSSL::SSL APPEND PROPERTY
+	INTERFACE_LINK_LIBRARIES "${CMAKE_DL_LIBS}")
   endif()
 endif()
 
-- 
2.9.2

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] daemon-mode: Project structure

[Alexander Neundorf]

On Thursday 09 June 2016 12:59:40 Tobias Hunger wrote:
> Hi Milian,
...
> > >   "targets":
> > >   [
> > > {
> > >   "fullName":"test",
> > >   "name":"test",
> > >   "type":"GLOBAL_TARGET"
> > > },
> > 
> > 
> > A nice-to-have would be a pointer to where the target got created, is
> > that feasible? That would allow an IDE to add a context menu to the
> > target list to jump to the CMakeLists.txt to edit the target.
> 
> 
> Stephen's work has lots of debugging features. It should be straight forward
> to figure out the location with those. So I am not sure it makes sense to
> add this here. Users sometimes define their targets in ways that are way
> too challenging to figure out with the little information available here
> (think macros and whatnot).

Getting the source directory of a target should be reliable and a useful 
information I guess ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [PATCH 1/1] Compiler/TI: Pass libraries as last part to linker

[Alexander Stein]

If e.g. libc.a is passed before any objects the linker raises the follwing
warning: cannot resolve archive libc.a to a compatible library, as no
input files have been encountered
In the end the library is skipped and missing symbols occur.

Signed-off-by: Alexander Stein 
---
 Modules/Compiler/TI-C.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Modules/Compiler/TI-C.cmake b/Modules/Compiler/TI-C.cmake
index 479666c..ebc79f4 100644
--- a/Modules/Compiler/TI-C.cmake
+++ b/Modules/Compiler/TI-C.cmake
@@ -7,4 +7,4 @@ set(CMAKE_C_CREATE_PREPROCESSED_SOURCE " 
--preproc_only --c_fi
 
 set(CMAKE_C_COMPILE_OBJECT  " --compile_only 
--c_file=--output_file=")
 set(CMAKE_C_ARCHIVE_CREATE " -r  ")
-set(CMAKE_C_LINK_EXECUTABLE " --run_linker 
--output_file= --map_file=.map  
  ")
+set(CMAKE_C_LINK_EXECUTABLE " --run_linker 
--output_file= --map_file=.map  
  ")
-- 
2.7.3

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

[Alexander Neundorf]

On Monday, February 22, 2016 22:30:42 Stephen Kelly wrote:
> Jean-Michaël Celerier wrote:
> > There is also https://www.cevelop.com/ which is an Eclipse derivative,
> > they may be interested ?
> 
> I went all hipster reach-out.io and tweeted at them. :)

looks like that's an FP7-project, so I wouldn't be too sure about its future 
once the project funding ends...

Alex


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

[Alexander Neundorf]

On Friday, February 19, 2016 11:36:35 Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Wednesday, February 17, 2016 22:59:36 Stephen Kelly wrote:
> >> On 02/15/2016 07:24 PM, Tobias Hunger wrote:
> >> > Hi Dominik,
> >> > 
> >> > Am 15.02.2016 19:01 schrieb "Dominik Haumann"
> >> >  >> > 
> >> > <mailto:dhaum...@kde.org>>:
> >> > > 1. Wouldn't it make sense you have a developer sprint ASAP for this?
> >> > 
> >> > I'd be in, but I do not have the time to organize one. I could
> >> > probably get a room in our office though (in Berlin).
> >> 
> >> I'd be up for a sprint in Berlin too, but given the muted response so
> >> far here, it's not clear who would want to join and what we could
> >> achieve.
> > 
> > just out of curiosity, did you get any feedback from anybody from
> > Eclipse/CDT ?
> 
> Nope. No response from there at all despite reaching out to them.

now that's a pity :-(

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

[Alexander Neundorf]

On Wednesday, February 17, 2016 22:59:36 Stephen Kelly wrote:
> On 02/15/2016 07:24 PM, Tobias Hunger wrote:
> > Hi Dominik,
> > 
> > Am 15.02.2016 19:01 schrieb "Dominik Haumann"  > 
> > >:
> > > 1. Wouldn't it make sense you have a developer sprint ASAP for this?
> > 
> > I'd be in, but I do not have the time to organize one. I could
> > probably get a room in our office though (in Berlin).
> 
> I'd be up for a sprint in Berlin too, but given the muted response so
> far here, it's not clear who would want to join and what we could achieve.

just out of curiosity, did you get any feedback from anybody from Eclipse/CDT 
? Or CodeBlocks maybe ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH]: CodeBlocks: improve support for different compilers

[Alexander Neundorf]

On Tuesday, February 16, 2016 10:49:24 Brad King wrote:
> On 02/12/2016 03:24 AM, melven.roehrig-zoell...@dlr.de wrote:
> > Just a small patch for the CodeBlocks generator
> 
> Thanks!  Applied:
> 
>  CodeBlocks: improve support for different compilers
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=184da3f4

Thanks :-)
Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

[Alexander Neundorf]

On Thursday, January 14, 2016 21:31:51 Kevin Funk wrote:
> On Wednesday, January 13, 2016 10:16:44 PM Alexander Neundorf wrote:
> > On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote:
> > > Running version 3.2.2 on Ubuntu 15. I run the following command:
> > > 
> > > $ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9
> > > -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config
> > > -DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake"
> > 
> > are you sure you actually want to use the KDevelop3 generator ?
> > This is for the KDE3 version, and you are probably using the KDE4 version
> > of KDevelop ? For that you don't need these generated project files.
> > 
> > Actually I was thinking about removing this generator, because KDevelop3
> > is
> > really really old, not sure whether it is still available in current Linux
> > distributions.
> > 
> > Alex
> 
> +1 from my side, KDevelop 3 is super ancient (last release around 2008
> according to the interwebs). Get rid off the generator.

Brad, what's  your opinion on this ?
Removing this is something I could do :-)

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake alternative language

[Alexander Neundorf]

On Wednesday, January 13, 2016 10:59:39 yann suisini wrote:
> Hi,
> 
> I'm a new user of CMake, but I just want to express my newcomer point of
> view.
> Honestly , I can feel the power of CMAKE, but it's a real pain to learn ...
> I'm using CMAKE for an embedded platform with a non GNU compiler , ant at
> the end the CMAKE description is longer than the one I built directly in
> Ninja.
> I had to write a python script to parse my eclipse project xml to create a
> list of sources files usable by CMAKE.
> The first thing I thought was: why this is not a part of cmake ? And the
> second thing was : why not using the scripting power of an existing
> language like Python(or other one) and add CMAKE as a framework / library ?

My personal opinion: if the full power of python would be available, the build 
scripts would quickly turn into real programs, because programmers would be 
tempted to do so if all of python would be available. Then developers would 
have to understand two programs: the program itself, and the "build program".

I'm not saying that the cmake language is beautiful, but it helps to keep 
cmake scripts somewhat simple, and not evolve into a second program 
additionally to the actual program which is being built.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

[Alexander Neundorf]

On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote:
> Running version 3.2.2 on Ubuntu 15. I run the following command:
> 
> $ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9
> -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config
> -DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake"

are you sure you actually want to use the KDevelop3 generator ?
This is for the KDE3 version, and you are probably using the KDE4 version of 
KDevelop ? For that you don't need these generated project files.

Actually I was thinking about removing this generator, because KDevelop3 is 
really really old, not sure whether it is still available in current Linux 
distributions.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake daemon for user tools

[Alexander Neundorf]

On Tuesday, January 12, 2016 23:20:14 Milian Wolff wrote:
> On Montag, 11. Januar 2016 23:22:23 CET Alexander Neundorf wrote:
...
> > Stephens big approach will need some time until it is ready, while such a
> > (relatively) simple thing can probably be done within one release cycle
> > (but I don't have the time to do it).
> > 
> > I don't know what the others here think about adding your json-approach or
> > not.
> 
> I don't think I'll have the required time to help here either, but I agree
> with your reasoning: Your patch is the potentially quickest to get something
> done. But it only fixes the usability issue of generators, it does not come
> with a useable generator which we'll still need to write.

I thought Aleix's patch was already quite good ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

[Alexander Neundorf]

On Tuesday, January 12, 2016 10:05:08 Brad King wrote:
> On 01/12/2016 05:15 AM, Tobias Hunger wrote:
> > I read Brad's reply as meaning that your cleanup work is a great
> > benefit to cmake, but will probably not be available in the
> > foreseeable future (if at all).
> 
> Most of Stephen's work completed so far is already in CMake 3.4, and
> a bit more is in 'master' and will be in 3.5.  It has no public-facing
> changes though so yes more work will be needed to get a solution IDEs
> can actually use.
> 
> > Alexander goes back to the generator approach we discussed a year ago
> > and explicitly says he won't work on that, so nothing will happen
> > there.
> 
> The generate-json-description approach remains a valid alternative.
> Aleix's work on it got pretty far before Stephen proposed the daemon
> alternative.  See more below.  IIRC Alexander Neundorf raised concerns
> only about how to activate the generation of the json description, and
> has now proposed an approach to resolve those concerns.

Yes, exactly.
But I really don't have the time to bring my branch up to merge quality: 
tests, documentation, compatibility (?, some generator names will fall away), 
corner cases. But these things are actually not complicated code, It's just 
work.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake daemon for user tools

[Alexander Neundorf]

On Monday, January 11, 2016 15:59:35 Aleix Pol wrote:
...
> 
> Hi Stephen, everyone,
> I've already discussed this in private with you. I think it's a good
> idea and I'd like to make sure we can benefit from this.
> 
> I'm unsure of the feasibility of the project though. 

you maybe remember that my main issue with your patch last year was that it's 
not a "generator", while it does what generators are for.
After talking with Milian a bit several week ago, I understood that an 
important reason why the kdevelop team does not want a generator is that there 
is only one generator per build-tree, i.e. the user has to decide beforehand 
which IDE project files he wants.
With the branch I created on github a few days ago, which I announced here 
too, I changed the way the extra generators are activated: they are not 
activated like the main generators anymore, but can be turned on and off using 
normal cmake cache options, so multiple generators (e.g. the generic json 
generator and let's say the Eclipse generator) can both be turned on, 
initially or later on. I think this should solve this problem.
The work there 
(https://github.com/neundorf/CMake/tree/RefactorExtraGeneratorsExperimental ) 
is not ready for inclusing, but it shows how it can be done and can serve as a 
starting point/inspiration.

Stephens big approach will need some time until it is ready, while such a 
(relatively) simple thing can probably be done within one release cycle (but I 
don't have the time to do it).

I don't know what the others here think about adding your json-approach or 
not.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] (Experimental) Refactored extra-generators

[Alexander Neundorf]

Hi,

I spent a few hours on the extra-generators, and you can find the result here 
on github:
https://github.com/neundorf/CMake/tree/RefactorExtraGeneratorsExperimental 

In this branch, the extra-generators are not tied anymore hardcoded to the 
generators (so the generator list is short again), but each extra-generator 
can be enabled and disabled via a cmake option 
CMAKE_ENABLE_EXTRA_GENERATOR_.
I.e. for every build directory zero, one or multiple extra-generators can be 
enabled and disabled (in an existing build tree).

This would e.g. also be suitable for a generic JSON-generator.

The code on github is not ready to be merged, and unfortunately I don't have 
the time to bring it into mergeable state, including tests, documentation, 
etc.

But if somebody is interested, you can have a look and give it a try.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Profile Cmake scripts

[Alexander Neundorf]

On Sunday, December 27, 2015 18:40:27 Dimitar Yordanov wrote:
> Hi all,
> 
> I was searching for a way to profile CMake scripts in order to find
> bottlenecks and possibilities to improve performance. I found out that
> someone already invested time on that [1] providing a minimal 
solution. The
> idea behind it is to use the cmake "--trace" option and to output a time
> stamp and a stack depth with each executed command. The trace log 
is
> afterwards used by a Python script, which transforms it into a more
> readable format.

I actually simply used valgrind/callgrind and got useful results from that.
Usually you see mostly string handling related functions.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] CMakeParseArguments: Test suite and native implementation

[Alexander Neundorf]

On Thursday, December 17, 2015 11:12:22 Brad King wrote:
> On 12/14/2015 04:52 PM, Matthias Männich wrote:
> > This adds a test suite for the CMakeParseArguments module. In 
addition
> > the second change implements cmake_parse_arguments(...) as 
native
> > command.
> 
> Thanks!  Applied with minor tweaks:


Cool :-)
Faster and one module less to load and care about :-)

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] set(CACHE) and the local scope

[Alexander Neundorf]

On Friday, December 11, 2015 14:44:39 Ben Boeckel wrote:
...
> Option 3:
> 
> set(CACHE) (and any other cache-touching behavior) does 
*nothing*
> with the cache if a local variable by that name is defined

just to clarify: and also does nothing to the local variable ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] set(CACHE) and the local scope

[Alexander Neundorf]

On Thursday, December 10, 2015 15:26:54 Brad King wrote:
> On 12/10/2015 03:20 PM, Alexander Neundorf wrote:
> >> set(var ON)
> >> option(var "description" OFF)
> >> message("var: ${var}")
> > 
> > I.e. on the first run it would be OFF (since that's the default value
> > of the option), and all later runs it would have the value which is in 
the
> > cache.
> This is calling for the opposite change than Ben's proposal.  Ben
> suggests never unsetting the local value to expose the cached value.
> Alex is suggesting always doing so, even if the cache option is
> not created by the command.
> 
> Alternatively the option() or set(CACHE) commands could also set
> a local variable to the same value as the cache entry.
> 
> This is pretty fundamental behavior so if we are going to mess with
> it through a policy we better get it right.

Yes. :-)

My motivation: if the option() would just set/get the cache variable, and 
leave the local variable untouched, it would be a NOOP in the example 
above, and this is not obvious from seeing that code.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] set(CACHE) and the local scope

[Alexander Neundorf]

On Wednesday, December 09, 2015 17:35:28 Ben Boeckel wrote:
> Hi,
> 
> So some behavior I was unaware of until today came up:
> 
> set(var ON)
> option(var "description" OFF)
> message("var: ${var}")

Assuming I wouldn't know about the subtle characteristics of normal vs. 
cache variables, I think I would expect that var has the value of the option 
afterwards.

I.e. on the first run it would be OFF (since that's the default value of the 
option), and all later runs it would have the value which is in the cache.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree

[Alexander Neundorf]

On Tuesday, December 08, 2015 11:14:07 Ben Boeckel wrote:
> On Tue, Dec 08, 2015 at 10:09:13 +0100, Attila Krasznahorkay wrote:
> > In the end I applied the following patch to CMake 3.4.1 locally to
> > speed it up for my use case very significantly. Of course this is not
> > a patch that could be applied to CMake for a general audience. But I
> > do think that if this code/behaviour could be switched on using
> > something like a directory property / global variable, a lot of users
> > could make good use of it. As it can be a reasonable assumption in
> > many development environments that only the changes inside of the
> > source tree should be tracked by the build system.
> 
> So some projects allow you to override specific headers (e.g., Boost) 
to
> provide  which would be included from the 
source
> tree. This file is not included directly by any users of Boost
> (usually), but instead included via other Boost headers, so scanning 
of
> system includes can be important.
> 
> So as long as there's an option/policy for it, I'm fine with the
> behavior. A policy could make it the default too with a directory
> property to re-enable global scanning.
> 
> Hmm…the build tree should also probably be allowed as well.

Yes.
I think I have also seen projects where the "top level"-CMakeLists.txt is 
actually not at the root of the project, but in a subdir, e.g. cmake/.
In that case all source files are outside ${CMAKE_SOURCE_DIR}.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Patch for FindCUDA (crosscompilation for arm64)

[Szakaly, Alexander]

Hi,
At my work we are using cmake for crosscompiling cuda-stuff for arm64 and the 
current FindCUDA-module has problems finding the cuda-libraries.

I have attached a patch that fixes the issue. It is based on master and 
formatted with git format-patch so should be possible to apply.
Please let me know what you think, it would be great if this could be included 
so we can stop manually patching it every time we update.

Best regards,
// AlexanderFrom 191c3c9a065d8b201b79816ddd94a361e8eed06b Mon Sep 17 00:00:00 2001
From: Alexander Szakaly 
Date: Mon, 23 Nov 2015 15:17:52 +0100
Subject: [PATCH] Add paths for crosscompiling with cuda for arm64

---
 Modules/FindCUDA.cmake | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 6a21078..ada5b8a 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -653,6 +653,9 @@ set(CUDA_VERSION_STRING "${CUDA_VERSION}")
 # Support for arm cross compilation with CUDA 5.5
 if(CUDA_VERSION VERSION_GREATER "5.0" AND CMAKE_CROSSCOMPILING AND CMAKE_SYSTEM_PROCESSOR MATCHES "arm" AND EXISTS "${CUDA_TOOLKIT_ROOT_DIR}/targets/armv7-linux-gnueabihf")
   set(CUDA_TOOLKIT_TARGET_DIR "${CUDA_TOOLKIT_ROOT_DIR}/targets/armv7-linux-gnueabihf" CACHE PATH "Toolkit target location.")
+# Support for aarch64 cross compilation with CUDA 7.0
+elseif(CUDA_VERSION VERSION_GREATER "6.5" AND CMAKE_CROSSCOMPILING AND CMAKE_SYSTEM_PROCESSOR MATCHES "aarch64" AND EXISTS "${CUDA_TOOLKIT_ROOT_DIR}/targets/aarch64-linux")
+  set(CUDA_TOOLKIT_TARGET_DIR "${CUDA_TOOLKIT_ROOT_DIR}/targets/aarch64-linux" CACHE PATH "Toolkit target location.")
 else()
   set(CUDA_TOOLKIT_TARGET_DIR "${CUDA_TOOLKIT_ROOT_DIR}" CACHE PATH "Toolkit target location.")
 endif()
-- 
1.9.1

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Generating buildsystem metadata from CMake

[Alexander Neundorf]

Hi,

On Saturday, July 25, 2015 20:33:46 Stephen Kelly wrote:
> Aleix Pol wrote:
> > On Sat, Apr 18, 2015 at 11:56 AM, Stephen Kelly
> > 
> >  wrote:
> >> Stephen Kelly wrote:
> >>> The aim is to generate a structured file containing metadata 
relating
> >>> the buildsystem.
> >> 
> >> I've been quiet on this thread for a while, so I think it is time for an
> >> update.
> >> 
> >> I became more ambitious in mid March and started prototyping a
> >> more-complete design for CMake IDE integration.
> > 
> > Hi Stephen,
> > Is there any news on the subject?
> 
> I have been working on cleaning up cmake
> 
>  $ git log --oneline --author=steveire --since="April 1" | wc -l
>  472
> 
> I've made lots of progress toward separating the configure and 
generation
> steps (required prerequisite for server features), but no working 
prototype
> ready to show yet I'm afraid.

Maybe this is of interest: the Eclipse CDT developers are currently 
working on improved support for cmake:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=350206
http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg29621.html

But if I understand them correctly, this is not about improving support for 
projects which use cmake without eclipse, but to use cmake as the tool 
to generate the makefiles in Eclipse projects. But maybe I got that 
wrong.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [ANNOUNCE] DaD's House! (Beta)

[Alexander Neundorf]

On Thursday, September 10, 2015 16:02:23 Konstantin Podsvirov wrote:
> The first 100 views!
> The interest is there (though not great), but where are the questions and
> suggestions?

the web page is quite short on details...
It's not an IDE, is it a set of scripts ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] A policy for Policies

[Alexander Neundorf]

On Saturday, June 20, 2015 11:29:46 Stephen Kelly wrote:
> Brad King wrote:
> > 
> 
> I recommend the following guidelines:
> 
> 1) Policies need to result in errors in a short timeframe. They are not
> something to ignore for years, because allowing that makes them feature
> toggles. Alex won't be happy with this one obviously, but that's what I
> recommend.

Just replace "Alex" with "Users who don't want to spend time babysitting their 
buildsystem, ".
 
> 2) Policies need to result in unconditional warnings in a short timeframe.
> Even -Wno-dev should have no effect on the warning when the warning is
> unconditional. If third parties are using -Wno-dev to silence output they
> need to know that will no longer work. It only works while there is an OLD
> state for the policy.
> 
> I don't think more conditions with deprecation states is a good idea. Policy
> lifecycle should be simple to understand. It should be a loud notification
> to people who see it that they have an action item on their hands.
> 
> Here's my recommendation for a way forward:
> 
> CMake 3.4:
> 
> * Policies <= CMP0011
> -- emit unconditional warnings for each policy (no OLD anymore - 6 years
> old)
> 
> * Policies CMP0051 -> CMP0054
> -- emit unconditional warnings for each policy (no OLD anymore - 3 releases
> old)
> 
> * Policies CMP0026, CMP0024
> -- emit unconditional warning (CMP0026 warning will be in place for longer
> as many are affected, so start unconditional warning now). These are high
> priority because they make a better CMake implementation possible.
> 
> CMake 3.5:
> 
> * Policies CMP0001, CMP0003, CMP0004, CMP0006 -> CMP0010
> -- emit unconditional errors for each policy (the ancient ones except 'the
> KDE4 policies')

Just so it doesn't sound only stupid: when I was still maintaining the KDE4 
buildsystem, I tried to avoid forcing users to have to update CMake (I always 
hate it if I try to do something on KDE, but instead of being able to start to 
do something, first I have to spend a day or two updating various stuff).
Ok, I wanted to avoid that for the cmake part.

So, let's say some version of KDE was released requiring CMake 2.4.5 (yeah, 
that old).
As long as there was no strong reason to require a newer version of CMake, I 
kept it at 2.4.5. Which implied, that the source should still be compilable 
with 2.4.5. Which, (at least to be on the safe side), also means, if there is 
a policy which results in a warning e.g. in 2.6.0, developers should not fix 
that warning with 2.6.0, since this might mean it does not work anymore with 
2.4.5.

Once a newer version of cmake is required, those policy settings may be 
changed. But even doing this means that developers may have to relearn some of 
their cmake skills, which is a cost, and shouldn't be forced without good 
reason.

Also, given the KDE4 source compatibility guarantees, kdebase 4.12 should 
still compile with kdelibs 4.3, and changing the cmake environments kde4libs 
is setting up influences this (and I had the impression that the uptake of 
more advanced cmake features in the wider KDE community was quite slow, e.g. 
learning about the subtleties of cmake policies).

So to me this still sounds reasonable.
 
...
> Of course all of this needs to be malleable. Let's see what the response is
> to the warning behavior in 3.4 if you apply it.

If there is a fixed date when the policy will result in an error, I'd consider 
it useful to have that date printed as part of the warning message.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] A policy for Policies

[Alexander Neundorf]

On Monday, June 08, 2015 09:57:14 Brad King wrote:
...
> This may be okay for CMP0011, but CMP0024 and CMP0026 were much
> more recent (3.0).  I think 5 years is a more reasonable cut-off
> than 2 years, especially given the time it takes CMake versions
> included in older distro releases to fall out of common use.

Yes, I fully agree, 2 years would be quite quite short.
The buildsystem should do its job, and not get in the way and create 
additional work.
I love that cmake still works on old projects, and doesn't fail when updating. 
I can remember all the hassle with autotools if some versions did not match, 
and I'm so happy that this is just not the case with cmake.

We have a lot of feature and time pressure at work (I guess most people around 
have that), and not having to babysit the cmake code for a long time is great.

If the conclusion would be a policy is removed after 5 years, it's deadline 
could even be part of the error/warning message right from the point when it 
is introduced ("you are relying on CMP1234 OLD behaviour. This will be removed 
June 2020.").

Then I could (at work) ignore this maybe until 2017 or 2018, and then it would 
slowly rise in my priority, and at some point I would fix it in some spare 
time.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Generating buildsystem metadata from CMake

[Alexander Neundorf]

On Monday, March 30, 2015 19:04:10 Anton Makeev wrote:
> > On 24 Mar 2015, at 00:54, Stephen Kelly  wrote:
> > 
> > Tobias Hunger wrote:
> >> How about include_directories, compile_definitions and compile_flags?
> >> 
> >> So something along the lines of:
> >> 
> >> "include_directories" : ["/foo", "/opt"]
> >> "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"]
> >> "compile_flags": [ "-c" ]
> > 
> > Quoting Anton:
> > 
> > Anton Makeev wrote:
> >> The other thing that seems troubling to me is that since file, target,
> >> language compiler options are split into different parts of metadata, the
> >> IDE need to know exactly how to assemble them back into the compiler’s
> >> command line (e.g. what flags go first file’s or language’s), duplicating
> >> CMake's logic that may be different from version to version and from
> >> compiler to compiler. The exact command line is needed to get the actual
> >> and precise defines, include search paths etc. from the compiler.
> > 
> > Maybe he can chime in with more. I don't really know why the entire
> > command
> > line is needed instead of separate "include_directories" and
> > "compile_definitions" arrays as you and I suggested. Perhaps because that
> > would not include -fPIC for example, which causes __PIC__ to be defined.
> > 
> > Another item of note is that CMake does not know the compile flags as a
> > sequential container of individual flags currently, but it knows them as a
> > string (that's also why it appears as a string in my generated json
> > currently).
> 
> The problem with the following format:
> ---
> "include_directories" : ["/foo", "/opt"]
> "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"]
> "compile_flags": [ "-c" ]
> —
> Is that it’s incomplete and cannot be used directly:
> * include directories list misses compiler-defined search paths
> * quote include directories are not distinguishable
> * compiler definition do not include compiler-defined(built-in) definitions
> etc.


Code for detecting the built-in include dirs and definitions is in 
CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake. This is used 
currently by CMakeFindCodeBlocks.cmake and CMakeFindEclipseCDT4.cmake, i.e. 
the respective extra-generators, and the information is generated into the 
eclipse/codeblocks project files.
This could be used here too.

I don't really understand your second point. Can you elaborate ?

Alex

P.S. Actually I still fail to understand why this generic json generator will 
be implemented differently then the other extra-generators. Those could also 
be changed to be variable-activated, instead of generator-activated, if this 
is preferred. Without checking the code, I don't think there is a technical 
reason not to do this.

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Fortran support for Ninja generator

[Alexander Neundorf]

On Wednesday, March 25, 2015 14:37:00 Steven Vancoillie wrote:
> On Mar 24 [11:21], Brad King wrote:
> > On 03/24/2015 05:46 AM, Nils Gladitz wrote:
> > > I am not very familiar with fortran myself but there was this discussion
> > > on the ninja mailing list that implied that this might also require
> > > changes to ninja itself:
> > > 
> > > https://groups.google.com/d/msg/ninja-build/b1-AF3pRJuE/NkPDsO0C2IUJ
> > 
> > That discussion concludes assuming that CMake scans source files
> > while generating the build files to generate the ordering dependencies.
> > It does not.  There could be generated source files or header files
> > that are needed to get the ordering right.  In the Makefile generator
> > we have a step to scan dependencies for a target after all its
> > dependencies are finished and its custom commands have executed.
> > This ensures generated files are available.  Then CMake puts the
> > dependency scanning results in a place used by the actual compile
> > and link rules.
> > 
> > [snip]
> > 
> > I've been thinking about some ideas on how build.ninja rules
> > could express the dynamic scanning and update we need.  Rather
> > than posting them now, perhaps the design process would benefit
> > from any independently developed ideas you may have.
> 
> From what I understood from the conclusion of the discussion is indeed
> that it would require cmake to generate dependency files at build
> time. In a test setup, I have the following:
> 
> build CMakeFiles/testninja.dir/prog.o.d: Fortran_DEPENDS_SCAN ../prog.f90
> build CMakeFiles/testninja.dir/prog.o: Fortran_COMPILER ../prog.f90 |
> CMakeFiles/testninja.dir/prog.o.d DEP_FILE =
> CMakeFiles/testninja.dir/prog.o.d
>   FLAGS = -cpp -I../
>   OBJECT_DIR = CMakeFiles/testninja.dir
>   OBJECT_FILE_DIR = CMakeFiles/testninja.dir
> build ...
> build ...
> 
> I skipped all the other files, but the pattern is the same.
> Then, there are these rules:
> 
> rule Fortran_DEPENDS_SCAN
>   command = f90deps $in $out
>   description = Write Fortran dependencies to $out
> 
> rule Fortran_COMPILER
>   depfile = $DEP_FILE
>   deps = gcc
>   command = /usr/bin/f95  $DEFINES $FLAGS -c $in -o $out
>   description = Building Fortran object $out
> 
> In this case, a script 'f90deps' does the dependencies on the fly.
> Note that the Fortran_COMPILER rule is now missing any -MMD/-MT stuff.
> 
> So, to do a similar thing with cmake, one would need to expose the
> cmake Fortran dependency scanner so that it can be invoked as e.g.:
> 
> rule Fortran_DEPENDS_SCAN
>   command = cmake scan_dependencies $in $out
>   description = Write Fortran dependencies to $out
> 
> but I don't know if turning the cmake executable into a build-time
> dependency scanner is feasible and/or acceptable.

as Brad wrote, this is already the case for the makefile generator, so I guess 
in general this should be Ok.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Extracting target metadata, IDE integration

[Alexander Neundorf]

On Sunday, March 15, 2015 18:00:25 Nils Gladitz wrote:
> On 15.03.2015 16:42, Tobias Hunger wrote:
> > Hi Peter,
> > 
> > CMake does know all the headers or it could not decide which files
> > need rebuilding.
> 
> The build system that CMake generates knows the header dependencies and
> decides when which files need rebuilding.
> CMake itself doesn't know. How header dependencies are determined and
> where and how they are recorded is generator specific.

I have spent enough time on this code, so:

for the makefile-generators, the header dependencies are generated by cmake 
(not at cmake time, but at build time), which results in the depend.make file.


Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Extracting target metadata, IDE integration

[Alexander Neundorf]

On Saturday, March 14, 2015 09:40:41 Peter Kümmel wrote:
> On 12.03.2015 16:24, Tobias Hunger wrote:
> > A list of *all* headers used during the building of the target would
> > be fine. There is no need to filter that list down in any way.
> > 
> > CMake has that information: Without it cmake could not possibly know
> > when a cpp file needs rebuilding. It would not be as successful a
> > build system when it did not know that:-)
> 
> Even cmake does not know all headers need for compilation, this is done
> by the compiler providing the dependency files.

the cmake dependency scanning does find all (and potentially some more) used 
headers, see depend.internal in the CMakeFiles/ tree.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Generating buildsystem metadata from CMake

[Alexander Neundorf]

On Wednesday, March 11, 2015 11:10:30 Stephen Kelly wrote:
> Hi,
> 
> Following from the thread here:
> 
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focu
> s=12394
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focu
> s=12650
> 
> I'm starting to gather requirements and make sure the feature is
> well designed to satisfy the needs we're already aware of, and fits with
> the features CMake currently has.
> 
> The aim is to generate a structured file containing metadata relating the
> buildsystem.
> 
> To help with completing the design of this feature, I've written
> documentation (documentation driven design), and a unit test
> containing a CMakeLists.txt file which exercises many modern CMake
> features in the "generate-metadata" branch in my clone.
> 
> Mostly the design I propose can be read in the documentation I wrote. I'm
> interested in any feedback.
> 
>  https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/
> Metadata/CMakeLists.txt
> http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.htm
> l
> 
> I expect to require a few iterations to figure out what the metadata files
> should contain in the end.  Note that there are already some differences
> between my design and Aleix's implementation, such as that my design
> proposes one metadata file per config. There are also some things
> missing like location, because it is not yet clear to me whether build
> or install locations are needed etc.
> 
> The content of the metadata file is determined by the build properties, and
> is necessarily similar to the compile-related content created when
> generating the actual buildsystem.  It additionally contains information
> about the output locations of build artifacts and information relating to
> the cmake description itself.
> 
> Goals include:
> 
> * Make it possible for IDEs to access the compile-related information for
>   autocompletion and code navigation etc purposes.
> 
> * Remove the need for IDEs to parse generated Makefiles or Ninja files to
>   access compile-related information.  The structure of those files is not
>   'stable', while the content of the metadata file is stable.
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412
> 
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus
> =11081
> 
> * Remove the need for users to create a new build directory and new build
>   in order to use or switch IDEs.  QtCreator requires that
>   the C::B 'extra generator is used as it parses compile information from
>   that.  Other 'extra generators' such as for eclipse, sublime, kate etc
>   also require fresh/new build directories, although the actual buildsystem
>   they create is identical (assuming using all Makefile based or
>   all Ninja based 'extra generators')

>From my POV, the json metadata is just another "extra generator", but one 
which can be always enabled additionally to other generators.
You say that users don't need new build directories for switching IDEs, but 
this is only under the assumption that the different IDEs will actually start 
to use this new file format.
See, users can use the C::B format and switch between CodeBlocks and 
QtCreator. If KDevelop and Kate would get plugins to read the C::B format 
(which is technically entirely possible) their users also would't have to 
create a new build directory.
So instead of adding generators to cmake which generate what the IDEs expect, 
this is a change, now cmake will generate a file and the IDEs are expected to 
follow.

My 2 cents
Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Extracting target metadata, IDE integration

[Alexander Neundorf]

On Monday, February 16, 2015 21:31:45 Aleix Pol wrote:
> On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly  wrote:
> > Aleix Pol wrote:
> >> Hi guys,
> >> It's been since August with this. I understand we're all busy but this
> >> step is important for KDevelop as well as for other IDE's and I
> >> wouldn't like this to rot.
> >> 
> >> Please, let's keep it moving forward.
> > 
> > As far as I'm aware, it needs to move forward from this point:
> >  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/fo
> >  cus=12151> 
> > I'm not certain the design is finished (eg what the file should contain
> > now
> > or eventually). I asked for tests/documentation as a way to trigger
> > getting
> > the design finished. Having either would give us a list of use-cases and
> > we
> > would know what's in scope and what's not in scope (eg whether compile
> > options/link options are in scope and why).
> 
> I can look further into documentation, if that's what holding us back.
> 
> > Another question: do you have any opinion about whether this should be one
> > global file or one file per directory? I don't know - it seems like
> > something that might or might not be relevant for tooling. Is the size of
> > the generated file a consideration?
> 
> I think the best is to have it all in 1 directory. You don't really
> want to have watchers on many files over there.
> 
> > How well does this feature work with large projects like VTK or a combined
> > build of LLVM/Clang/lldb/libcxx/other ll projects.
> 
> I just generated the file for LLVM: https://paste.kde.org/pxl8ozwah
> It's a 127KiB file, I don't think it's too mental considering it's a
> 330 MiB repository.

I didn't follow the whole thread, just a few quick questions from looking at 
the file:


{
   "name": "obj2yaml",
   "type": "EXECUTABLE",
   "configs": [
  ],
   "directory": "/home/kde-devel/tmp/llvm/build/bin",
   "location": "/home/kde-devel/tmp/llvm/build/bin/obj2yaml",
   "backtrace": ["/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:452",
 "/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:485",
 "/home/kde-devel/tmp/llvm/tools/obj2yaml/CMakeLists.txt:6"],
   "installed": true
},


I guess "name" is the name of the target, type, configs, location, backtrace 
and installed seem to be clear.

What about "directory" ?
This is not the build dir where the target is defined (i.e. 
cmake_binary_dir(llvm/tools/obj2yaml/), is it ?
This directory would seem useful to me, e.g. you can run "make help" there to 
get the list of targets to compile/assemble/preprocess the files for that 
target. Or you can run the clean-script for that target.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Extracting target metadata, IDE integration

[Alexander Neundorf]

On Tuesday, December 23, 2014 01:30:58 Aleix Pol wrote:
> On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev
...
> > * No progress indication. Since the generation may take several minutes,
> > 
> >   providing feedback is crucial.
> 
> I never found such case, I would argue that a project which has a
> cmake script that takes several minutes is broken, but maybe we can
> open a thread to discuss it?

On network file systems things can get slow... (even if the file system feels 
really fast in general usage, i.e. has high data throuhgput).

...
> > * Not sure if it’s possible at all - a lightweight phase where CMake only
> > 
> >   collects necessary information (list of files/targets, compiler
> >   settings).
> >   This will help IDE react to the changes much faster.
> 
> That would be extra-cool, agreed. Maybe it's an iteration we can
> consider in the future.


Yes, this would be cool, but until now whenever I thought about this my 
conclusion was that this is unfortunately not possible, since the 
targets/files/etc. can depend on anything, if() clauses, execution of 
commands, results of find_package(), etc.
 
Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [DISCUSSION] Using COMPONENTs for CMake install(...)?

[Alexander Neundorf]

On Wednesday, December 03, 2014 00:50:52 Konstantin Podsvirov wrote:
> CMake is being developed for a long time, but does not use COMPONENTs during
> installation. Why?
> 
> The command install(...) allows you to specify the COMPONENT. Why this
> feature is not used by CMake?
> 
> Is it possible to split the install CMake on COMPONENTs? Further it can be
> used when creating redistributable packages.

you can use them when calling the cmake_install.cmake manually, instead of 
calling "make install": cmake -DCOMPONENT="MyComponent" -P cmake_install.cmake


I think at least some of the package generators support the components too.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Was AUTOMOC designed to run for each build?

[Alexander Neundorf]

On Friday, September 26, 2014 01:53:35 Stephen Kelly wrote:
> Alexander Neundorf wrote:
> >> I don't see why the target is executed each time, but is it that way by
> >> design?
> > 
> > iirc, yes.
> > The moc files have to be generated before any of the source files is
> > compiled, so automoc is in a target the actual target depends on.
> > IIRC it is exclude_from_all so that it is only built when the actual
> > target is built.
> > Do you think it should only rerun if any of the source files has changed ?
> > There was some problem with this.
> > The headers are usually not part of the listed source files.
> 
> Hmm, well, we do know which header is relevant right? Because it's the one
> (or many) we set up commands to run moc on. Maybe we only know the relevant
> headers too late (at the time of running the -E cmake_autogen command, not
> at cmake time)?
> 
> Something else I've wondered is why the parsing of the files is done
> 'delayed' with the -E cmake_autogen command. Is it just to avoid doing that
> task during cmake time (because it's time consuming), and to allow
> parallelization?

it can't be done at cmake time, because editing a cpp file and inserting 
#include "foo.moc" does not cause cmake to rerun, so the parsing must happen 
during buildtime.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Extracting target metadata, IDE integration

[Alexander Neundorf]

On Thursday, September 25, 2014 07:14:38 Anton Makeev wrote:
...
> Here is why I think the discussed functionality should not be a separate
> generator:
> 
> CLion doesn’t have it’s own project model nor is intended as build tool
> replacement. Currently, the only option for CLion users is makefiles build,
> that is not a best option for everyone: there is a good and fast
> alternative ‘Ninja’. Ideally, users should be able to choose whatever tool
> better suites them.
> 
> The problem is that the generated Makefiles are used both, for internal
> needs, like reading project structure, and also to build and run the user’s
> program. If we wanted to support Ninja generator, we would need to rewrite
> all the logic that retrieves the project information, using the files that
> are created by Ninja generator. While I suppose it’s possible, it’s not the
> best option - very error prone and resource demanding.
> 
> If CMake generated a separate descriptor, regardless the generator used
> (Makefiles, Ninja), it would be much easier to support; and the users will
> benefit from better, more reliable and faster CMake integration in an IDE.

not sure I fully understand, but it seems you are maybe not aware how the 
"extra generators" in cmake work.

Those are basically run additionally to a "normal" generator. I.e. cmake 
generates makefiles or ninja files, and additionally project files for an IDE. 
This project file typically contains the list of targets, and for each target 
the build command. At that point it doesn't matter much anymore for the IDE 
whether the main generator is make or ninja.
This is implemented with the Eclipse generator, the CodeBlocks generator and 
the Kate generator. They all write a project file for the IDE additionally to 
the makefiles/ninja files for the actual building.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Was AUTOMOC designed to run for each build?

[Alexander Neundorf]

On Tuesday, September 23, 2014 09:58:58 Stephen Kelly wrote:
> Hi (especially Alex),
> 
> I noticed that the automoc target is run each time, even for a trivial
> project:
> 
>  cmake_minimum_required(VERSION 2.8)
>  project(automoctest)
> 
>  set(CMAKE_AUTOMOC ON)
> 
>  find_package(Qt5Widgets REQUIRED)
> 
>  add_executable(main main.cpp)
>  target_link_libraries(main Qt5::Widgets)
> 
> Each time I run make I get
> 
>  [ 33%] Automatic moc for target main
>  /path/to/cmake -E cmake_autogen /path/to/build/CMakeFiles/main_automoc.dir/
> "
> 
> I checked CMake 2.8.7 and it executes the target each time too.
> 
> In the implementation, makefile->AddUtilityCommand is called with 'true' to
> set the excludeFromAll parameter.
> 
> I don't see why the target is executed each time, but is it that way by
> design?

iirc, yes.
The moc files have to be generated before any of the source files is compiled, 
so automoc is in a target the actual target depends on.
IIRC it is exclude_from_all so that it is only built when the actual target is 
built.
Do you think it should only rerun if any of the source files has changed ?
There was some problem with this.
The headers are usually not part of the listed source files. I would have to 
check to find out the details again.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Extracting target metadata, IDE integration

[Alexander Neundorf]

On Friday, September 19, 2014 21:53:40 Alexander Neundorf wrote:
> On Friday, September 19, 2014 13:44:45 Brad King wrote:
> ...
> 
> > * Don't IDEs want to know the list of source files so they can
> > 
> >   be used for editing?
> > 
> > I haven't looked at what the Extra generators produce in a
> > while but since they are meant for IDEs they would be a good
> > reference for the information needed.
> 
> typically a list of targets, the command to build each target, source files
> for each target, used include dirs and defines (-D) for code completion.
> 
> > However, AFAIK there
> > is not an extra generator for a multi-config generator.
> 
> Yes.

also after reading the other replies, I still don't understand why this 
shouldn't be a generator.
If I understand correctly, this is for people who simply run cmake and later 
on want to use kdevelop on the existing build tree.

How about simply adding support for an environment variable like 
"CMAKE_GENERATOR", which, when set, will be used as generator as long as no 
other generator has been set via -G ?
KDE developers could set this variable, still run their build scripts, and 
later on use kdevelop.

I have a hard time imagining a user who uses let's say Eclipse with the 
Eclipse generator, who then suddenly wants to use kdevelop on his build tree.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Extracting target metadata, IDE integration

[Alexander Neundorf]

On Friday, September 19, 2014 13:44:45 Brad King wrote:
...
> * Don't IDEs want to know the list of source files so they can
>   be used for editing?
> 
> I haven't looked at what the Extra generators produce in a
> while but since they are meant for IDEs they would be a good
> reference for the information needed. 

typically a list of targets, the command to build each target, source files 
for each target, used include dirs and defines (-D) for code completion.

> However, AFAIK there
> is not an extra generator for a multi-config generator.

Yes.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Gold standard find module?

[Alexander Neundorf]

On Wednesday, September 10, 2014 10:38:44 Richard Shaw wrote:
> On Wed, Sep 10, 2014 at 7:18 AM, David Cole  wrote:
> > > In this case just the one. I'm not that ambitious as I'm just
> > > volunteering my time to various FOSS projects and still have to
> > > maintain a day job to pay the bills!
> > 
> > In that case, I would recommend just getting it into shape so that it
> > works best for you. (But then, that's the way we've ended up with so
> > many ways of doing things in the find modules we do have) As you
> > submit changes for review, though, hopefully the reviewers will catch
> > anything that is not recommended and ask you to revise it before
> > pushing it into 'master'.
> 
> That's kinda what I was thinking as well but some of the problem I'm trying
> to fix are requiring some significant changes that looking at a simple diff
> may not really be helpful...
> 
> > I think asking specific questions when you have something you're not
> > sure of is better than trying to identify a gold standard find module
> > on which to model your contributions.
> 
> I'm sure I'll still have plenty of questions, I was just hoping to have a
> really good example to go by to catch the easy stuff.

Just a few things:
- variables should be named ExactCaseName_SOMETHING
- try to detect the version number
- use find_package_handle_standard_args() in the new mode
- make sure it works also on systems without pkg-config


Alex


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Extracting target metadata, IDE integration

[Alexander Neundorf]

On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote:
> On Tue, Sep 2, 2014 at 3:58 PM, David Cole  wrote:
> > It makes sense. But what IDE are you referring to? Eclipse? Some other
> > concrete example? Or just "any IDE and this feature should work everywhere
> > CMake works...?"
> 
> I'm working on KDevelop, I know for a fact though, that other IDEs are
> looking for something similar too, such as QtCreator.

I still don't understand why this shouldn't be an additional ExtraGenerator.
It will generate a special file intended to be used by KDevelop and maybe 
QtCreator additionally to makefiles/ninja files. Could be called "GenericJSON" 
or so.
Other IDEs which don't support this file type but which need their own project 
file obviously still need their own specific generator.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Extracting target metadata, IDE integration

[Alexander Neundorf]

On Tuesday, September 02, 2014 09:58:37 David Cole via cmake-developers wrote:
> It makes sense. But what IDE are you referring to? Eclipse? Some other
> concrete example? Or just "any IDE and this feature should work
> everywhere CMake works...?"

AFAIK it is kdevelop4, and the goal is that developers don't have to tell 
cmake to run a kdevelop4 generator, but just the normal makefile generator, 
and still be able to use kdevelop4 on these build trees.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Extracting target metadata, IDE integration

[Alexander Neundorf]

On Monday, September 01, 2014 15:26:12 David Cole via cmake-developers wrote:
> The approach looks reasonable, but having it unconditionally spit out a
> file in cmGlobalGenerator regardless of generator is probably not what
> we want. Seems like it should be based on a variable, or be in a
> specific generator, or somehow have a limited scope.

I agree. IMO this should be a generator, I don't see why it should work around 
that.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] find_package() verbosity

[Alexander Neundorf]

On Tuesday, August 26, 2014 10:41:04 Nils Gladitz wrote:
> Are there any official recommendations or opinions on how verbose a find
> module (or package configuration file) should be on success?
> 
> - Find modules using FindPackageHandleStandardArgs report success once.
> 
> - FindBoost.cmake reports success every time.
> 
> - Qt5 package configuration files (and find_package() in CONFIG mode
> specifically) keep quiet on success.

I think the recommendation is to report when it fails, and whenever something 
changes in the successful result, i.e. on the first success and potentially if 
on a later run some additionaly module or something has been found. IOW what 
FindPackageHandleStandardArgs.cmake does.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] What about #line like feature in cmake language?

[Alexander Neundorf]

On Thursday, May 22, 2014 09:16:17 Brad King wrote:
> On 05/21/2014 04:05 PM, Nicolas Desprès wrote:
> > at the time the AST node is created the file location is frozen.
> > Locations are controlled by the lexer so do comments.
> 
> Correct.  This has to be done by the lexer.  We already have
> documentation blocks that are "indistinguishable from comments":
> 
>  #.rst:
>  # ...reStructuredText docs...
> 
>  #[=[.rst:
>  ...reStructuredText docs...
>  #]=]
> 
> I see no reason this can't be used for #line too:
> 
>  #.cmake-source-line: 1234 "/path/to/real/file"
> 
> In all of the above cases there is no semantic meaning to the
> comments as far as the CMake language processor is concerned.
> The last case only changes the file names and line numbers in
> backtraces.
> 
> One remaining challenge is CMAKE_CURRENT_LIST_FILE and
> CMAKE_CURRENT_LIST_LINE. 

Probably also CMAKE_CURRENT_LIST_DIR.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] dpkg-shlibdeps

[Alexander Neundorf]

On Monday, May 19, 2014 13:06:17 Kornel Benko wrote:
> Am Montag, 19. Mai 2014 um 12:59:31, schrieb Nils Gladitz
> 
> > On 05/19/2014 12:50 PM, Kornel Benko wrote:
> > > I am using CPACK with
> > > 
> > >   set(CPACK_DEBIAN_PACKAGE_DEBUG ON)
> > > 
> > > There is one offending output
> > > 
> > >   CPackDeb Debug: dpkg-shlibdeps version is <>
> > > 
> > > Looking into CPackDeb.cmake, the regex for getting the version
> > > searches 'dpkg-shlibdeps version ([0-9]+\\.[0-9]+\\.[0-9]+)'
> > > from output of 'dpkg-shlibdeps --version'.
> > > 
> > > But in my case (ubuntu 12.10), this is not matching, since the command
> > > returns> > 
> > >   'Debian dpkg-shlibdeps Version 1.16.7.
> > >   ...'
> > > 
> > > Could the regex please be replaced by
> > > 
> > >   'dpkg-shlibdeps [vV]ersion ([0-9]+\\.[0-9]+\\.[0-9]+)'
> > > 
> > > ?
> > > 
> > > This is cmake version 3.0.20140511-g17c650
> > 
> > Looks like the whole string is localized
> > e.g. Norwegian: "Debian %s versjon %s.\n".
> 
> Yes, you are right. My localization was German.
> 
> > Perhaps the whole non numeric prefix should be skipped.
> 
> +1

I guess the locale should be reset before calling the executable.
That's what's done also in other places.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMP0043 warnings everywhere

[Alexander Neundorf]

On Tuesday, April 29, 2014 16:38:56 Brad King wrote:
> On 04/29/2014 04:25 PM, Alexander Neundorf wrote:
> >> Or, you could fix your project to not use the behavior deprecated
> >> by the policy.
> > 
> > Other reasons are e.g. avoiding to annoy your developer team by warnings
> > which don't matter (the build has been working, so there's no need to
> > change it).
> Yes, there is a need to change it.  CMake deprecated an interface.
> The project should stop using it and use the replacement interface
> instead.  The CMP0043 documentation explains how and gives examples.

I was talking in general about these warnings.
Typically some project  has a working build system (...otherwise it wouldn't 
build), and after updating cmake, warnings appear.
Since the build is working, there is no immediate need (for the project) to 
change anything in the buildsystem.
The project will have an urgent need to change it once the old behaviour is 
not supported anymore.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMP0043 warnings everywhere

[Alexander Neundorf]

On Monday, April 28, 2014 13:39:09 Brad King wrote:
> On 04/28/2014 01:26 PM, James Bigler wrote:
> > I thought the purpose of policies was to keep some backward compatibility
> > feature, but allow users to select the new behavior.
> 
> The purpose is to change CMake interfaces or behavior while still
> building existing project releases that have not been updated by
> their developers to understand the new behavior:
> 
>  http://www.cmake.org/Wiki/CMake/Policies
> 
> > Now I'm forced to set this policy to OLD in order to not have a million
> > warnings spam my team.
> 
> Or, you could fix your project to not use the behavior deprecated
> by the policy.  

Other reasons are e.g. avoiding to annoy your developer team by warnings which 
don't matter (the build has been working, so there's no need to change it).

Or, correct me if I'm wrong, isn't it possible that by fixing a warning the 
project then requires the cmake version which added the warning ?
Which would mean fixing the warning would break the build with the (old) 
required cmake version ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMP0043 warnings everywhere

[Alexander Neundorf]

On Monday, April 28, 2014 10:26:56 James Bigler wrote:
> > -Original Message-
> > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On
> > Behalf Of Brad King
> > Sent: Wednesday, April 23, 2014 11:06 AM
> > To: cmake-developers@cmake.org
> > Subject: Re: [cmake-developers] CMP0043 warnings everywhere
> > 
> > On 04/23/2014 12:57 PM, James Bigler wrote:
> > > I'm getting tons of CMP0043 warnings on my existing project.
> > > 
> > > I have cmake_policy(VERSION 2.6) set in my project.
> > > Why am I being pestered by warnings?  Shouldn't I get a policy value
> > > appropriate for 2.6 (so CMP0043 should be set to OLD)?
> > 
> > Setting policies by VERSION leaves policies newer than that version unset,
> > not set to OLD.  If it were to set them to OLD then no new policies would
> > ever warn. There is intentionally no way to turn off warnings about
> > policies newer than those known to the project code, except by using
> > -Wno-dev locally. Otherwise developers would never see the warnings and
> > know to update their code.
> 
> I thought the purpose of policies was to keep some backward compatibility
> feature, but allow users to select the new behavior.  In this case, setting
> the behavior for new policies to OLD seems the most logical, especially
> when I asked for it with cmake_policy(VERSION).  Now I'm forced to set this
> policy to OLD in order to not have a million warnings spam my team. 

if(POLICY CMP0043)
   cmake_policy(SET CMP0043 OLD)
endif()

you might wrap that into a macro, so you just hand in the list of (new) 
policies.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] cmake --find-package

[Alexander Neundorf]

On Friday, April 25, 2014 12:10:30 Alan W. Irwin wrote:
> On 2014-04-24 22:41+0200 Alexander Neundorf wrote:
> > On Wednesday, April 23, 2014 14:45:45 Alan W. Irwin wrote:
> >> On 2014-04-23 22:40+0200 Alexander Neundorf wrote:
> >>> On Wednesday, April 23, 2014 13:21:39 Alan W. Irwin wrote:
> >>>> On 2014-04-23 13:21-0400 Bill Hoffman wrote:
> >>>>> On 4/23/2014 12:22 PM, Alan W. Irwin wrote:
> >>>>>> However, if you discover the problem is a general one for
> >>>>>> --find-package and Qt5, then it appears that Qt5 might be a good
> >>>>>> illustrative example to use for your renewed effort at developing a
> >>>>>> reliable --find-package capability.
> >>>>> 
> >>>>> I recently ran into a project using --find-package and found a
> >>>>> limitation
> >>>>> that could be very problematic.  If a find module in CMake uses a
> >>>>> try-compile, or tries to figure out anything to do with the compiler,
> >>>>> this
> >>>>> command will fail.I am not sure there is a good way around this.
> >>>>> Certainly try-compile is not actively discouraged in the CMake
> >>>>> Modules,
> >>>>> so
> >>>>> this can be added to any module at any time, breaking --find-package
> >>>>> in
> >>>>> the
> >>>>> future.
> >>>> 
> >>>> Hi Bill:
> >>>> 
> >>>> You cannot use --find-package unless you specify the language.  So I
> >>>> assume that --find-package enables the specified language, and, in
> >>>> general, you would think that try-compile would work properly under
> >>>> those circumstances.
> >>> 
> >>> No.
> >>> 
> >>> It doesn't really enable a language, it only loads a bunch of files to
> >>> set
> >>> the most urgently required variables.
> >>> Most of it is implemented in CMakeFindPackageMode.cmake
> >>> 
> >>> It is basically wrapping a find_package() call, setting up just enough
> >>> to
> >>> make it succeed usually.
> >>> try_compile() will fail.
> >>> 
> >>> My plan was to limit this mode to Config.cmake files only, but as I
> >>> said,
> >>> due to the changes in CMake this has become too much work, so I won't
> >>> work on that in the forseeable future.
> >> 
> >> Hi Alex:
> >> 
> >> The question that remains is will --find-package be maintained
> >> indefinitely for CMake-3.x?
> > 
> > I can't guarantee.
> > Since modern Config.cmake files don't follow the old convention of setting
> > a _LIBRARIES and a _INCLUDE_DIRS variable anymore, which is the basic
> > assumption the --find-package feature was based on, I don't really feel
> > motivated to fix this.
> > 
> >> As I said, --find-package is the only way
> >> I know how to obtain required compile and link flags for Qt5 at the
> >> present time (assuming the patch for the library name screwup is
> >> accepted for the CMake support files in Qt5, but that is a separate
> >> Qt5 issue compared to whether or not you decide to maintain
> >> --find-package for CMake-3.x).  Until I discovered this thread, I had
> >> assumed that the --find-package option would be maintained
> >> indefinitely for CMake so I haven't looked further at other
> >> alternatives yet.
> >> 
> >> Assuming you or someone else decides to remove the --find-package
> >> capability now or sometime during CMake-3.x (which from my point of
> >> view makes sense if you are not going to maintain it),
> > 
> > I wouldn't object.
> > This is actually the first time I get serious feedback for that feature, I
> > had the impression nobody uses it or considers it useful.
> 
> Hi Alex:
> 
> I hadn't attempted to use this feature myself up to now because most
> of the PLplot build system was implemented long before --find-package
> was implemented.  But, in general, I think --find-package is an
> excellent idea since ideally (assuming try-compile is not used) it
> should supply users with the essential compile and link flags needed
> for a dependency while relieving them of the burden of figuring out
> details of the CMake-based build system for that dependency.  That's a
> large potential benefit for a typ

Re: [cmake-developers] cmake --find-package

[Alexander Neundorf]

On Wednesday, April 23, 2014 14:45:45 Alan W. Irwin wrote:
> On 2014-04-23 22:40+0200 Alexander Neundorf wrote:
> > On Wednesday, April 23, 2014 13:21:39 Alan W. Irwin wrote:
> >> On 2014-04-23 13:21-0400 Bill Hoffman wrote:
> >>> On 4/23/2014 12:22 PM, Alan W. Irwin wrote:
> >>>> However, if you discover the problem is a general one for
> >>>> --find-package and Qt5, then it appears that Qt5 might be a good
> >>>> illustrative example to use for your renewed effort at developing a
> >>>> reliable --find-package capability.
> >>> 
> >>> I recently ran into a project using --find-package and found a
> >>> limitation
> >>> that could be very problematic.  If a find module in CMake uses a
> >>> try-compile, or tries to figure out anything to do with the compiler,
> >>> this
> >>> command will fail.I am not sure there is a good way around this.
> >>> Certainly try-compile is not actively discouraged in the CMake Modules,
> >>> so
> >>> this can be added to any module at any time, breaking --find-package in
> >>> the
> >>> future.
> >> 
> >> Hi Bill:
> >> 
> >> You cannot use --find-package unless you specify the language.  So I
> >> assume that --find-package enables the specified language, and, in
> >> general, you would think that try-compile would work properly under
> >> those circumstances.
> > 
> > No.
> > 
> > It doesn't really enable a language, it only loads a bunch of files to set
> > the most urgently required variables.
> > Most of it is implemented in CMakeFindPackageMode.cmake
> > 
> > It is basically wrapping a find_package() call, setting up just enough to
> > make it succeed usually.
> > try_compile() will fail.
> > 
> > My plan was to limit this mode to Config.cmake files only, but as I said,
> > due to the changes in CMake this has become too much work, so I won't
> > work on that in the forseeable future.
> 
> Hi Alex:
> 
> The question that remains is will --find-package be maintained
> indefinitely for CMake-3.x?  

I can't guarantee.
Since modern Config.cmake files don't follow the old convention of setting a 
_LIBRARIES and a _INCLUDE_DIRS variable anymore, which is the basic assumption 
the --find-package feature was based on, I don't really feel motivated to fix 
this.

> As I said, --find-package is the only way
> I know how to obtain required compile and link flags for Qt5 at the
> present time (assuming the patch for the library name screwup is
> accepted for the CMake support files in Qt5, but that is a separate
> Qt5 issue compared to whether or not you decide to maintain
> --find-package for CMake-3.x).  Until I discovered this thread, I had
> assumed that the --find-package option would be maintained
> indefinitely for CMake so I haven't looked further at other
> alternatives yet.
> 
> Assuming you or someone else decides to remove the --find-package
> capability now or sometime during CMake-3.x (which from my point of
> view makes sense if you are not going to maintain it), 

I wouldn't object.
This is actually the first time I get serious feedback for that feature, I had 
the impression nobody uses it or considers it useful.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] cmake --find-package

[Alexander Neundorf]

On Wednesday, April 23, 2014 13:21:39 Alan W. Irwin wrote:
> On 2014-04-23 13:21-0400 Bill Hoffman wrote:
> > On 4/23/2014 12:22 PM, Alan W. Irwin wrote:
> >> However, if you discover the problem is a general one for
> >> --find-package and Qt5, then it appears that Qt5 might be a good
> >> illustrative example to use for your renewed effort at developing a
> >> reliable --find-package capability.
> > 
> > I recently ran into a project using --find-package and found a limitation
> > that could be very problematic.  If a find module in CMake uses a
> > try-compile, or tries to figure out anything to do with the compiler, this
> > command will fail.I am not sure there is a good way around this.
> > Certainly try-compile is not actively discouraged in the CMake Modules, so
> > this can be added to any module at any time, breaking --find-package in
> > the
> > future.
> 
> Hi Bill:
> 
> You cannot use --find-package unless you specify the language.  So I
> assume that --find-package enables the specified language, and, in
> general, you would think that try-compile would work properly under
> those circumstances.

No.

It doesn't really enable a language, it only loads a bunch of files to set the 
most urgently required variables.
Most of it is implemented in CMakeFindPackageMode.cmake

It is basically wrapping a find_package() call, setting up just enough to make 
it succeed usually.
try_compile() will fail.

My plan was to limit this mode to Config.cmake files only, but as I said, due 
to the changes in CMake this has become too much work, so I won't work on that 
in the forseeable future.

Alex


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] cmake --find-package (was: Roadmap to CMake 3.0)

[Alexander Neundorf]

On Wednesday, April 23, 2014 09:22:09 Alan W. Irwin wrote:
> On 2013-10-19 20:16+0200 Alexander Neundorf wrote:
> > On Thursday 17 October 2013, Stephen Kelly wrote:
> >> Brad King wrote:
> >>> On 10/17/2013 04:58 PM, Alexander Neundorf wrote:
> >>>> Yes, that was the idea, but I can't rely anymore on a Foo_LIBRARIES
> >>>> variable (or a slight variation) being set after a successful
> >>>> find_package(Foo):
> >>>> http://lists.kde.org/?l=kde-core-devel&m=138198795723680&w=2 I.e. in
> >>>> the
> >>>> future there will be Find-modules which typically export one of
> >>>> (Foo|FOO)_(LIBRARIES|LIBRARY), some Config.cmake files which do that
> >>>> too, and a big number, probably majority, of Config.cmake files, which
> >>>> do not export such variables.
> >>>> 
> >>>> The only chance I see would be to simply collect all library targets
> >>>> and
> >>>> return what they provide, but this doesn't feel good. I would have much
> >>>> prefered using a clear interface like the Foo_LIBRARIES variable.
> >>> 
> >>> Perhaps we need to establish a convention for find modules and package
> >>> configuration files to interact with --find-package mode.  I have no
> >>> thoughts on the specifics of how that would work though.
> >> 
> >> A new, similar --find-target mode or similar may be more appropriate:
> >>  cmake --find-target --package Qt5Widgets --target Qt5::Widgets ...
> >>  
> >>  # KF5Config exports 3 independent targets:
> >>  cmake --find-target --package KF5Config --target KF5::ConfigCore ...
> >>  cmake --find-target --package KF5Config --target KF5::ConfigGui ...
> >>  cmake --find-target --package KF5Config --target KF5::ConfigWidgets ...
> > 
> > Yes, that will work.
> > And a new command/option is not even necessary.
> > The name of the target could be given as additional option.
> > If none is given, it will use the variables as it does now, if a target is
> > given, it will use this target and its properties.
> > 
> > I'll work on that when I find the time (and nobody is faster).
> 
> How is that going, Alex?

I have more or less given up on this.
Due to all the changes in cmake recently (not recommending setting variables 
anymore in find_package(), and all the target property stuff), this would 
require quite some work, and I seriously don't have that much time for cmake 
currently.
Also, one of the big benefits, not having to read documentation for every 
package anymore, but having a standard interface, is lost, AFAICS.

So, if somebody wants to pick that up, feel free.

Sorry
Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] New EVIS parser moving forward (3.1)

[Alexander Neundorf]

On Friday, February 21, 2014 14:32:18 Brad King wrote:
> On 02/21/2014 02:18 PM, Jean-Christophe Fillion-Robin wrote:
> > If possible, not having implicit expansion for quoted argument
> > would be great at make things more intuitive and practical.
> 
> This has been discussed before.  It will take some refactoring
> of the CMake language command processing implementation to
> tell commands, like if(), about the delimiters used for each
> argument: unquoted, quoted, or bracket arguments. 


Yes.
A simple stupid way to fix the problem for STREQUAL would be to add an 
alternative comparison operator to if(), which never expands variables, and 
leave STREQUAL as it is. E.g.

if ("${Foo}" == "Bar")

No risk, easy to do, no backwards compatibility issues, but somewhat ugly, as 
was concluded the last time this was discussed here.

Alex

-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Tests and cmake_minimum_required question

[Alexander Neundorf]

On Saturday, February 15, 2014 13:12:41 Steve Wilson wrote:
> When developing a new feature, we add tests to the test suite.   Some of
> those tests require CMakeLists.txt with the cmake_minimum_required(VERSION
> …)/project() commands.   If you are testing a brand new feature, what
> version number should be used with cmake_minimum_required?

since the cmake which has just been built will be used, requiring the current 
version should be ok.
OTOH, beside setting policies, it shouldn't matter much, except in cases where 
policies are involved.

Alex

-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Request for review of topic "intel-visibility"

[Alexander Neundorf]

On Friday, February 07, 2014 05:33:47 PM Stephen Kelly wrote:
> Nils Gladitz wrote:
> > On 02/07/2014 04:24 PM, Brad King wrote:
> >> This looks correct to me and is a good bug fix.  Please merge
> >> to 'next' for testing.
> > 
> > Thanks, will do!
> > 
> >> Do you have access to Intel C/C++ on OS X that you could use to try
> >> this task?
> > 
> > I currently only have access to Intel on Windows which is why I thought
> > it safer to put the topic up for review first too.
> 
> Does intel on windows have separate gcc-like and msvc-like modes?
>
> Alex also adjusted the intel handling of -isystem today. Does that work if
> the direct preprocessor flag "-Wp,-isystem," is used, if there's some

Would there be an advantage compared to using -isystem ?
AFAIK -isystem is not supported by icpc under Windows, and from looking at 
other files in cmake -isystem seems in general not to be supported under OSX.
But I have access only to icpc under Linux, so I can't check.

Alex

-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Wednesday 29 January 2014, Brad King wrote:
> On 1/28/2014 4:20 PM, Alexander Neundorf wrote:
> >> (1) Design new behavior in a way that requires a change to the
> >> 
> >> project to activate.
> > 
> > I think my current version fits (1).
> 
> Yes, I meant to add "like Alex's topic currently does".
> 
> > IMO this is not the place for a policy, since the behaviour of the
> > existing, unchanged project did not change, it is still working as it
> > did before.
> 
> ...except for the case of set(PROJECT_VERSION) *before* a call to
> project() without a VERSION.  Currently your solution using
> CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND avoids needing the
> policy.  However, it is not a design that would have been
> produced if we were starting from scratch.  The purpose of a
> policy is to allow us to switch to the clean design while
> remaining compatible with existing code.
> 
> > Regarding (2): how should I detect whether PROJECT_VERSION has been set
> > manually ?
> 
> Actually I realized we don't have to detect that.  What matters
> is that project() may clear the variable values when it did not
> before.
> 
> I reverted the 'AddVersionToProjectCommand' topic from 'next'
> and replaced it with a 'project-version-variables' topic that
> adds a policy:
> 
>  Help: Format project command and variable documentation
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dcc
> 
>  project: Add optional LANGUAGES keyword
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=16d040c9
> 
>  project: Manage VERSION variables
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e142c5a
> 
>  write_basic_package_version_file: use PROJECT_VERSION
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41d2f2c4
> 
> The key is that project() only accepts VERSION when the
> policy is set to NEW.  After release this will be automatic
> because one would need cmake_minimum_required() to specify a
> high enough version to understand the new project() signature
> and that would set the policy to NEW.  Once the policy is
> set to NEW then we can freely clear variables when project()
> is not given a VERSION.

Fine with me, thanks :-)

Alex
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Tuesday 28 January 2014, Brad King wrote:
> On 01/23/2014 04:08 PM, Alexander Neundorf wrote:
> > Any more comments left ?
> 
> Moving the discussion from
> 
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9156/focu
> s=9158
> 
> back to the thread where it belongs:
> 
> On 01/27/2014 04:58 PM, Stephen Kelly wrote:
> > Though I still don't like the behavior in the topic with project()
> > commands without a specified VERSION and the
> > CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND variable etc. I don't see
> > why all the complexity is needed.
> > 
> > From what I understand, the reason it was added is related to using
> > add_subdirectory to add a self-contained/standalone project to host
> > buildsystem.
> 
> My main concern that the VERSION complexity solves is for changing
> behavior of existing projects that are *not* modified at all.  We've
> established that a project() without VERSION needs to unset the
> PROJECT_VERSION variables because otherwise they would not correspond
> to the current PROJECT_NAME.  However, an existing project could do
> 
>  # CMakeLists.txt
>  project(Top)
>  set(PROJECT_VERSION 1.0.0)
>  add_subdirectory(Sub)
> 
>  # Sub/CMakeLists.txt
>  project(Sub)
>  message(STATUS "Top version = ${PROJECT_VERSION}")
> 
> Since previous versions of CMake documented no special behavior
> for the PROJECT_VERSION variable this code is completely fine
> now, but would suddenly change in behavior if project() started
> to unset PROJECT_VERSION.
> 
> So our options are
> 
> (1) Design new behavior in a way that requires a change to the
> project to activate.
> 
> (2) Add a policy.  The policy should only trigger when the
> project() command is about to unset a PROJECT_VERSION
> variable that was set by user code and not by a previous
> project() command.


I think my current version fits (1).
If nothing is changed in a project, the behaviour will not change at all (if 
it does, I have overseen something).

Things only start to change once a VERSION is added to a project() call.
Then, if a following project() call without VERSION sees the PROJECT_VERSION 
variable set, and sees that CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND is 
set to TRUE, it unsets the PROJECT_VERSION.
This means it does not unset it if the user has manually set the variable and 
not added VERSION to any project() call.

The only condition where things will break (but still only after the user has 
actually modifed the project), is the following:

CMakeLists.txt:

project(Foo VERSION 1.2.3)

set(PROJECT_VERSION 4.5.6)

sub/CMakeLists.txt:

project(Bar)


IMO this is not the place for a policy, since the behaviour of the existing, 
unchanged project did not change, it is still working as it did before.

The issue above (which is probably unlikely), can be worked around by manually 
unsetting the guard variable:

CMakeLists.txt:
project(Foo VERSION 1.2.3)
unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND)

set(PROJECT_VERSION 4.5.6)

sub/CMakeLists.txt:

project(Bar)

That's not too nice, but IMO a reasonable solution for fixing that hopefully 
rare error case.

Regarding (2): how should I detect whether PROJECT_VERSION has been set 
manually ?
I had some code which did that, but only if the version set via SET() was 
different than the version set via PROJECT(). I.e. it would work almost 
always, but in the cases where it wouldn't work, it would be very weird and 
hard to find. I don't think this would have been good behaviour.
Alternatively probably something could be done with variable_watch, but to me 
this seems a bit heavy for this purpose. I mean, it's only a rare breakage 
after a manual change to a project, and then all set() calls would be checked, 
always.

I still think what I merged into next is Ok.
I can add a few more test cases, no problem.
I asked for more comments last Thursday, and there were none until I merged 
into next on Saturday.

I know that it would have been nice to squash the two actual code commits into 
one...
I tried that two weeks ago or so, and I (or git, depending on how you see it) 
messed up my branches.
Asking google verified that squashing anything into the first commit of a 
branch is not really supported by git.
I didn't consider it worth it to try to follow the recipes suggested here 
http://stackoverflow.com/questions/598672/git-how-to-squash-the-first-two-
commits or in other places just to merge the two commits into one.
The history is not messy, it's just one commit which could have been squashed. 
But even as they are they are not really hard to read.

Alex
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Monday 06 January 2014, Alexander Neundorf wrote:
> Hi,
> 
> on cmake stage I have a simple branch AddVersionToProjectCommand.
> This extends the project command to also accept a version number:
> 
> project(Foo VERSION 1.2.3 CXX)
> 
> All that does is setting some more variables (beside PROJECT_NAME,
> PROJECT_SOURCE_DIR, PROJECT_BINARY_DIR and the _...
> equivalents).
> 
> When setting a version, you also get PROJECT_VERSION and
> PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK) variables as well as the
> _... equivalents.
> 
> These version variables can then be used in other commands/macros/functions
> which need a version.
> I modified write_basic_package_version_file() accordingly, so that you can
> now simply do
> 
> project(Foo VERSION 1.2.3)
> 
> ...
> 
> write_basic_package_version_file(FooConfigVersion.cmake
>  COMPATIBILITY AnyNewerVersion)
> 
> and this will use the version number from the project() call automatically
> (if no VERSION has been given explicitely).


Ok, I force-pushed my AddVersionToProjectCommand branch again.
Documentation is fixed, and after Steves comment not to overdo it with 
protecting the user from its own changes I removed the check for the actual 
value of PROJECT_VERSION again, since I think in case this breaks something, 
this will be very weird for the user.

I'd like to merge that into next soon.

Any more comments left ?

Alex
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Tuesday 21 January 2014, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Sunday 19 January 2014, Stephen Kelly wrote:
> >> Alexander Neundorf wrote:
> >> > This is now in the AddVersionToProjectCommand branch on git stage.
> >> > 
> >> > Please have a close look at it.
> >> 
> >> The documentation is not formatted correctly as rst.
> > 
> > I looked at the generated html file, it seemed to look ok.
> > What's wrong with it ?
> 
> +# If no VERSION is given, the version number specified via
> +# project(... VERSION x.y.z ...) is used. If this hasn't been set, it
> errors
> +# out.
> 
> ... to:
> 
>  specified via :command:`project(VERSION)`
> 
> I didn't look for other problems or opportunities for better docs. I just
> noticed that, and it indicates you haven't looked into what can/should be
> done with rst yet. I suggest you look for those opportunities.

Ah, ok.

Is it actually recommended to use some formatting, like bold or italic or 
something else ?

Alex
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Sunday 19 January 2014, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > This is now in the AddVersionToProjectCommand branch on git stage.
> > 
> > Please have a close look at it.
> 
> The documentation is not formatted correctly as rst.

I looked at the generated html file, it seemed to look ok.
What's wrong with it ?

Alex
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Sunday 19 January 2014, Alexander Neundorf wrote:
> On Wednesday 15 January 2014, Matthew Woehlke wrote:
> > On 2014-01-15 16:25, Alexander Neundorf wrote:
> > > On Wednesday 15 January 2014, Alexander Neundorf wrote:
> > >> And, to actually produce the breakage, at some place the VERSION
> > >> argument must have been added.
> > >> With the current state of my branch, this could be worked around by
> > >> unsetting the guard variable:
> > >> 
> > >> 
> > >> project(Foo VERSION 1.2.3)
> > >> 
> > >> 
> > >> unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND)
> > >> add_subdir(B)
> > >> 
> > >> This way B would be protected from that change in behaviour.
> > > 
> > > I could also add more logic, to try to detect if PROJECT_VERSION has
> > > been set manually, e.g. project() could reset PROJECT_VERSION only if
> > > it has the same value as ${${ParentProjectName}_VERSION}. Then it
> > > would only break if there was a manual set(PROJECT_VERSION ...) before
> > > a project() call without VERSION, and if that manually set version was
> > > the same as the version in the "parent project".
> > 
> > IMHO your last suggestion (very good idea, btw!) is more than adequate,
> > especially given the original weakness of my "objection" (which was
> > always more along the lines of "did you consider this case, and should
> > we worry about it?").
> 
> This is now in the AddVersionToProjectCommand branch on git stage.
> 
> Please have a close look at it.
> 
> I'm not sure I like that somewhat magic behaviour how it decides whether to
> unset() the variables or not.
> There will be problems with this very rarely, but when the circumstances
> occur, it may be quite hard to figure out.
> I.e. it could happen when the version number of a sub-project changes, then
> suddenly PROJECT_VERSION could be empty afterwards:
> 
> CMakeLists.txt:
> 
> project(Parent VERSION 1.0.0)
> 
> add_subdirector(sub)
> 
> sub/CMakeLists.txt:
> - set(PROJECT_VERSION 0.0.1)
> + set(PROJECT_VERSION 1.0.0)
>   project(Foo)
>   message(STATUS "Version: ${PROJECT_VERSION})
> 
> Such a patch would have the effect that PROJECT_VERSION in suddenly empty
> in the message() call.
> 
> I would probably prefer to not touch the PROJECT_VERSION variables at all
> if VERSION is not used, then there are at least no (very rare) surprises
> or sudden breakages.
> 
> Alex

I could maybe also do something with variable_watch(), but I haven't used this 
yet at all. It probably would have somne performance impact I guess.

Alex

-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Wednesday 15 January 2014, Matthew Woehlke wrote:
> On 2014-01-15 16:25, Alexander Neundorf wrote:
> > On Wednesday 15 January 2014, Alexander Neundorf wrote:
> >> And, to actually produce the breakage, at some place the VERSION
> >> argument must have been added.
> >> With the current state of my branch, this could be worked around by
> >> unsetting the guard variable:
> >> 
> >> 
> >> project(Foo VERSION 1.2.3)
> >> 
> >> 
> >> unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND)
> >> add_subdir(B)
> >> 
> >> This way B would be protected from that change in behaviour.
> > 
> > I could also add more logic, to try to detect if PROJECT_VERSION has been
> > set manually, e.g. project() could reset PROJECT_VERSION only if it has
> > the same value as ${${ParentProjectName}_VERSION}. Then it would only
> > break if there was a manual set(PROJECT_VERSION ...) before a project()
> > call without VERSION, and if that manually set version was the same as
> > the version in the "parent project".
> 
> IMHO your last suggestion (very good idea, btw!) is more than adequate,
> especially given the original weakness of my "objection" (which was
> always more along the lines of "did you consider this case, and should
> we worry about it?").

This is now in the AddVersionToProjectCommand branch on git stage.

Please have a close look at it.

I'm not sure I like that somewhat magic behaviour how it decides whether to 
unset() the variables or not.
There will be problems with this very rarely, but when the circumstances 
occur, it may be quite hard to figure out.
I.e. it could happen when the version number of a sub-project changes, then 
suddenly PROJECT_VERSION could be empty afterwards:

CMakeLists.txt:

project(Parent VERSION 1.0.0)

add_subdirector(sub)

sub/CMakeLists.txt:
- set(PROJECT_VERSION 0.0.1)
+ set(PROJECT_VERSION 1.0.0)
  project(Foo)
  message(STATUS "Version: ${PROJECT_VERSION})

Such a patch would have the effect that PROJECT_VERSION in suddenly empty in 
the message() call.

I would probably prefer to not touch the PROJECT_VERSION variables at all if 
VERSION is not used, then there are at least no (very rare) surprises or 
sudden breakages.

Alex
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Wednesday 15 January 2014, Alexander Neundorf wrote:
> On Wednesday 15 January 2014, Matthew Woehlke wrote:
> > On 2014-01-14 18:00, Alexander Neundorf wrote:
> > > On Tuesday 14 January 2014, Matthew Woehlke wrote:
> > >> While that sounds good for 99.9% of cases, what about the case of
> > >> project A that includes project B, where B is not updated, but A
> > >> decides to start using project(...VERSION...). Now if B was using
> > >> PROJECT_VERSION internally, it is broken. (Note that I'm implying that
> > >> B is e.g. a separate repository that may not be "as easy to
> > >> update/fix as A".)
> > > 
> > > You mean
> > > CMakeLists.txt:
> > > 
> > > project(Foo VERSION 1.2.3)
> > > 
> > > 
> > > 
> > > add_subdir(B)
> > > 
> > > B/CMakeLists.txt:
> > > 
> > > set(PROJECT_VERSION "4.5.6")
> > > project(Bar)
> > > 
> > > 
> > > Indeed.
> > > In that case, PROJECT_VERSION will be unset afterwards.
> > 
> > Exactly. I wanted to point it out, but as that's probably unusual, I
> > would be okay ignoring that case.
> > 
> > > If it would be
> > > 
> > > B/CMakeLists.txt:
> > > 
> > > 
> > > project(Bar)
> > > set(PROJECT_VERSION "4.5.6")
> > > 
> > > everything is fine.
> > 
> > ...until B/C/CMakeLists.txt also calls project() :-). Basically, you
> > (can) get into trouble if you "update" your project to use
> > project(VERSION) and also have an "external" sub-project that tries to
> > use PROJECT_VERSION. However, as much as folks¹ occasionally bleat about
> > this use case (having an embedded "external" project), I suspect it's
> > not actually very common², and anyway there is only a problem when the
> > sub-project *also* uses PROJECT_VERSION (which I suspect is also rare in
> > general, and more so the intersection of the two).
> > 
> > Again, given the above, I've no objection to breaking that case, which
> > may well only exist in the hypothetical sense with no 'in the wild'
> > instances actually existing.
> 
> And, to actually produce the breakage, at some place the VERSION argument
> must have been added.
> With the current state of my branch, this could be worked around by
> unsetting the guard variable:
> 
> 
> project(Foo VERSION 1.2.3)
> 
> 
> unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND)
> add_subdir(B)
> 
> This way B would be protected from that change in behaviour.

I could also add more logic, to try to detect if PROJECT_VERSION has been set 
manually, e.g. project() could reset PROJECT_VERSION only if it has the same 
value as ${${ParentProjectName}_VERSION}. Then it would only break if there 
was a manual set(PROJECT_VERSION ...) before a project() call without VERSION, 
and if that manually set version was the same as the version in the "parent 
project".

Or, maybe, project() without VERSION should simply NOT clear PROJECT_VERSION.
Then it may be a somewhat inconsistent or not ideal behaviour, but OTOH there 
is zero chance for breaking an existing build by adding a VERSION somewhere.

Alex
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Wednesday 15 January 2014, Matthew Woehlke wrote:
> On 2014-01-14 18:00, Alexander Neundorf wrote:
> > On Tuesday 14 January 2014, Matthew Woehlke wrote:
> >> While that sounds good for 99.9% of cases, what about the case of
> >> project A that includes project B, where B is not updated, but A decides
> >> to start using project(...VERSION...). Now if B was using
> >> PROJECT_VERSION internally, it is broken. (Note that I'm implying that B
> >> is e.g. a separate repository that may not be "as easy to update/fix as
> >> A".)
> > 
> > You mean
> > CMakeLists.txt:
> > 
> > project(Foo VERSION 1.2.3)
> > 
> > 
> > 
> > add_subdir(B)
> > 
> > B/CMakeLists.txt:
> > 
> > set(PROJECT_VERSION "4.5.6")
> > project(Bar)
> > 
> > 
> > Indeed.
> > In that case, PROJECT_VERSION will be unset afterwards.
> 
> Exactly. I wanted to point it out, but as that's probably unusual, I
> would be okay ignoring that case.
> 
> > If it would be
> > 
> > B/CMakeLists.txt:
> > 
> > 
> > project(Bar)
> > set(PROJECT_VERSION "4.5.6")
> > 
> > everything is fine.
> 
> ...until B/C/CMakeLists.txt also calls project() :-). Basically, you
> (can) get into trouble if you "update" your project to use
> project(VERSION) and also have an "external" sub-project that tries to
> use PROJECT_VERSION. However, as much as folks¹ occasionally bleat about
> this use case (having an embedded "external" project), I suspect it's
> not actually very common², and anyway there is only a problem when the
> sub-project *also* uses PROJECT_VERSION (which I suspect is also rare in
> general, and more so the intersection of the two).
> 
> Again, given the above, I've no objection to breaking that case, which
> may well only exist in the hypothetical sense with no 'in the wild'
> instances actually existing.

And, to actually produce the breakage, at some place the VERSION argument must 
have been added.
With the current state of my branch, this could be worked around by unsetting 
the guard variable:


project(Foo VERSION 1.2.3)


unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND)
add_subdir(B)

This way B would be protected from that change in behaviour.

Alex
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Tuesday 14 January 2014, Matthew Woehlke wrote:
> On 2014-01-14 10:37, Brad King wrote:
> > On 01/13/2014 01:38 PM, Alexander Neundorf wrote:
> >> does this require a policy now ?
> >> 
> >> Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a
> >> project(Foo)
> >> call in a subdir, which would now unset Foo_VERSION_MAJOR.
> >> The same for PROJECT_VERSION_MAJOR, but this is maybe less likely.
> > 
> > I don't think project(Foo) needs to affect Foo_VERSION_* when no
> > VERSION argument is given (but should handle empty VERSION "").
> > It should still handle PROJECT_VERSION_* to ensure consistency
> > with PROJECT_NAME.  That may need a policy, but it will be tricky
> > because we need to know if the value came from a previous project()
> > call or a user set() in order to know when to trigger compatibility.
> > 
> > Perhaps "project(... VERSION ...)" can set some cmMakefile variable
> > internally that says the project knows about versions so it is okay
> > project(Foo) calls to unset them in subdirs.  Then we won't need any
> > policy because there is no change in behavior without modifying the
> > project to add at least one VERSION to a project() command.
> 
> While that sounds good for 99.9% of cases, what about the case of
> project A that includes project B, where B is not updated, but A decides
> to start using project(...VERSION...). Now if B was using
> PROJECT_VERSION internally, it is broken. (Note that I'm implying that B
> is e.g. a separate repository that may not be "as easy to update/fix as
> A".)

You mean
CMakeLists.txt:

project(Foo VERSION 1.2.3)

...

add_subdir(B)

B/CMakeLists.txt:

set(PROJECT_VERSION "4.5.6")
project(Bar)


Indeed.
In that case, PROJECT_VERSION will be unset afterwards.

If it would be 

B/CMakeLists.txt:


project(Bar)
set(PROJECT_VERSION "4.5.6")

everything is fine.

Alex
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Tuesday 14 January 2014, Brad King wrote:
> On 01/13/2014 01:38 PM, Alexander Neundorf wrote:
> > does this require a policy now ?
> > 
> > Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a
> > project(Foo)
> > call in a subdir, which would now unset Foo_VERSION_MAJOR.
> > The same for PROJECT_VERSION_MAJOR, but this is maybe less likely.
> 
> I don't think project(Foo) needs to affect Foo_VERSION_* when no
> VERSION argument is given (but should handle empty VERSION "").
> It should still handle PROJECT_VERSION_* to ensure consistency
> with PROJECT_NAME.  That may need a policy, but it will be tricky
> because we need to know if the value came from a previous project()
> call or a user set() in order to know when to trigger compatibility.
> 
> Perhaps "project(... VERSION ...)" can set some cmMakefile variable
> internally that says the project knows about versions so it is okay
> project(Foo) calls to unset them in subdirs.  Then we won't need any
> policy because there is no change in behavior without modifying the
> project to add at least one VERSION to a project() command.

I updated the topic on stage, it basically does that now.
I haven't updated the test yet.

Alex
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Friday 10 January 2014, Alexander Neundorf wrote:
> On Friday 10 January 2014, Brad King wrote:
> > On 01/06/2014 04:41 PM, Alexander Neundorf wrote:
> > > I modified write_basic_package_version_file() accordingly, so that you
> > > can now simply do
> > > 
> > > project(Foo VERSION 1.2.3)
> > > 
> > > ...
> > > 
> > > write_basic_package_version_file(FooConfigVersion.cmake
> > > 
> > >  COMPATIBILITY AnyNewerVersion)
> > > 
> > > and this will use the version number from the project() call
> > > automatically (if no VERSION has been given explicitely).
> > 
> > One problem left to address is what to do when a project() command is
> > invoked in a subdirectory.  It will set PROJECT_NAME, PROJECT_SOURCE_DIR,
> > and PROJECT_BINARY_DIR but it should also *unset* the PROJECT_VERSION_
> > variables if no VERSION argument is provided.  Otherwise the version
> > values will not be consistent with the project name.
> 
> right, unsetting sounds good.


does this require a policy now ?

Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a 
project(Foo)
call in a subdir, which would now unset Foo_VERSION_MAJOR.
The same for PROJECT_VERSION_MAJOR, but this is maybe less likely.

Alex
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Friday 10 January 2014, Alexander Neundorf wrote:
> On Friday 10 January 2014, Brad King wrote:
> > On 01/06/2014 04:41 PM, Alexander Neundorf wrote:
> > > I modified write_basic_package_version_file() accordingly, so that you
> > > can now simply do
> > > 
> > > project(Foo VERSION 1.2.3)
> > > 
> > > ...
> > > 
> > > write_basic_package_version_file(FooConfigVersion.cmake
> > > 
> > >  COMPATIBILITY AnyNewerVersion)
> > > 
> > > and this will use the version number from the project() call
> > > automatically (if no VERSION has been given explicitely).
> > 
> > One problem left to address is what to do when a project() command is
> > invoked in a subdirectory.  It will set PROJECT_NAME, PROJECT_SOURCE_DIR,
> > and PROJECT_BINARY_DIR but it should also *unset* the PROJECT_VERSION_
> > variables if no VERSION argument is provided.  Otherwise the version
> > values will not be consistent with the project name.
> 
> right, unsetting sounds good.

I added that to the AddVersionToProjectCommand branch on stage, along with a 
test.

Alex
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Friday 10 January 2014, Brad King wrote:
> On 01/06/2014 04:41 PM, Alexander Neundorf wrote:
> > I modified write_basic_package_version_file() accordingly, so that you
> > can now simply do
> > 
> > project(Foo VERSION 1.2.3)
> > 
> > ...
> > 
> > write_basic_package_version_file(FooConfigVersion.cmake
> > 
> >  COMPATIBILITY AnyNewerVersion)
> > 
> > and this will use the version number from the project() call
> > automatically (if no VERSION has been given explicitely).
> 
> One problem left to address is what to do when a project() command is
> invoked in a subdirectory.  It will set PROJECT_NAME, PROJECT_SOURCE_DIR,
> and PROJECT_BINARY_DIR but it should also *unset* the PROJECT_VERSION_
> variables if no VERSION argument is provided.  Otherwise the version
> values will not be consistent with the project name.

right, unsetting sounds good.

Should the full version "1.2.3" be put into PROJECT_VERSION or 
PROJECT_VERSION_STRING ?
Both forms are used in different places in cmake.

Alex
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

[Alexander Neundorf]

On Friday 10 January 2014, Matthew Woehlke wrote:
> On 2014-01-10 11:01, Jean-Christophe Fillion-Robin wrote:
> > Would it make sense to have "project(Foo VERSION 1.2.3)" set the 
variables:
> >${PROJECT_NAME}_PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK)
> > 
> > That way, the variable would remain even if project is called with
> > VERSION in sub directory.
> 
> How is that different? Do you mean to drop the PROJECT_VERSION_{...}
> entirely? That doesn't seem desirable for symmetry with the other
> PROJECT_{...} variables.
> 
> I think I'm with Brad; set the PROJECT_VERSION_{...} and
> ${PROJECT_NAME}_VERSION_{...} (note; no extra literal 'PROJECT') as
> usual. Always. Whether or not VERSION was specified (i.e. unset the
> corresponding variables in such case).
> 
> Folks that use the PROJECT_{...} forms hopefully know what they are
> doing, otherwise people are hopefully using the ${PROJECT_NAME}_{...}
> forms instead.
> 
> 
> Related: Do these affect the version properties of libraries? (Because
> OTOH if it does, I can imagine wanting to say VERSION once at the root
> and have it inherit downwards unless overridden. Maybe though that's a
> reason for it to not do so.)

I thought about that too.
Even without it, with the patch you now already have a standard form:

set_target_properties( PROPERTIES VERSIOn ${PROJECT_VERSION} )

Automatically doesn't really work, or at least it would have to be switched 
on:
set(CMAKE_USE_PROJECT_VERSION_FOR_LIBRARIES TRUE)
and then that property would automatically use ${PROJECT_VERSION}.

But that doesn't have to be done now, it can also be done later on.

Alex
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] cmake --help-custom-modules compatibility

[Alexander Neundorf]

On Wednesday 08 January 2014, you wrote:
> On 11/20/2013 07:22 PM, Stephen Kelly wrote:
> >> The solution is still to re-implement the "--help-custom-modules
> >> myman.1" command-line behavior as a special case with warnings.  Alex
> >> and Steve will have to work out who takes responsibility for that.
> > 
> > I'll defer to Alex on doing that I think.
> 
> Alex, Steve, we need to resolve this compatibility issue soon
> in preparation for the 3.0 release.  

since a few weeks I only sporadically find some time :-), so don't rely on me, 
I can't promise anything currently.

Alex
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Generators and Extra Generators

[Alexander Neundorf]

On Tuesday 07 January 2014, Stephen Kelly wrote:
> David Cole wrote:
> > There's been a design issue since extra generators were introduced...
> > 
> > The question is: is it possible to resolve it with a better design and
> > still keep the existing functionality?
> 
> Hence this mail :), and my mail to cmake.users about the "Kate Extra
> Generator" being the wrong interface/design.
> 
> I'd like to see cmake generate all the info a UI would need in a simple and
> non-tied-to-a-particular-implementation way. That would be something Qt
> Creator and Kate could use as it would list the targets, the compile lines
> for objects, link targets, link lines etc. 

Actually an IDE may have somewhat different needs.
As long as it uses an existing buildtool (make or ninja), it doesn't actually 
need the commands for linking, and also not necessarily for compiling. (if the 
IDE would execute e.g. the link commands directly instead of calling "make 
foo", then the IDE would need to be a complete buildtool, i.e. with full 
dependency handling between the targets etc.).
It does need information which include dirs and definitions are used, per 
target, probably better per source file, so it can do proper completion etc.
IMO it needs information in which CMakeLists.txt a target has been added, to 
support the user by editing the cmake files.
It needs to know to which target(s) a source file belongs, and vice versa, it 
needs to know the language of each source file (since this can be overridden 
via the LANGUAGE property in cmake).
I'm quite sure IDE developers can think of more they'd like to know.

As I said, it would be really cool if this information could be put complete 
and IDE-independent in a project file. 

Alex
--

Powered by www.kitware.com

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

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

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