Re: [cmake-developers] CMake API for warnings

2016-04-22 Thread Ruslan Baratov via cmake-developers

On 22-Apr-16 20:36, Brad King wrote:

On 04/20/2016 09:50 AM, Ruslan Baratov wrote:

1) add_compile_warnings
* similar to add_definitions, add_compile_options
* modify COMPILE_WARNINGS directory property (append)
2) target_compile_warnings
* similar to target_compile_options, target_compile_definitions
* modify COMPILE_WARNINGS target property (append)
3) source_files_compile_warnings
* similar to set_source_files_properties
* modify COMPILE_WARNINGS sources property (append)

Sounds good.  Note that cmTarget has dedicated storage with backtrace
information for other build system properties.  Please use the same
pattern for these.  I also suggest getting the directory/target level
working first and work on source files later.  The infrastructure for
the latter is not as mature so it may need more work.


*_compile_warnings(

DISABLE  # add =off to COMPILE_WARNINGS
property
ENABLE  # add =on to COMPILE_WARNINGS
property
TREAT_AS_ERROR  # add =error to
COMPILE_WARNINGS property
)

Sounds good.


* all (compiler specific "all", e.g. /Wall or -Wall)
* default
* level
* none
* everything (all possible warnings for compiler, if there is no such
option use maximum level plus some warnings explicitly)

Okay.  Let's drop level for now for the reason you outlined.
We can always add it later.


Properties will be set in form =on|off|error, e.g.:

add_compile_warnings(DISABLE undef unused ENABLE inline TREAT_AS_ERROR 
everything)

will set COMPILE_WARNINGS directory property to:

undef=off unused=off inline=on everything=error

Good.


In case of any conflicts return CMake warning for developer message
(cmake -Wdev/cmake -Wno-dev).

Good.


Directory properties affect targets and sources, target properties
affect sources of this target. E.g.:

  add_compile_warnings(DISABLE undef)
  target_compile_warnings(foo DISABLE unused)

effectively equivalent to:

  target_compile_warnings(foo DISABLE undef unused)

Question: do we need to control this? probably by
'target_compile_warnings(foo DISABLE unused IGNORE DIRECTORY)' ?

It should be possible to merge the directory/target/source settings
with proper precedence.  I don't understand your example well enough
to see what "IGNORE DIRECTORY" would mean.  Either way, such information
needs to be encoded somehow in the property values.


It means ignoring directory properties. So by default we will inherit 
settings. Target will inherit directory properties:


add_compile_warnings(DISABLE warn-A)
target_compile_warnings(foo DISABLE warn-B)

COMPILE_WARNINGS of target 'foo' property value:

warn-A=off warn-B=off

Sources:

add_compile_warnings(ENABLE warn-A)
target_compile_warnings(foo ENABLE warn-B)
source_files_compile_warnings(foo.cpp ENABLE warn-C)

COMPILE_WARNINGS of 'foo.cpp' property value:

warn-A=on warn-B=on warn-C=on

To disable inheriting we need to add extra argument (?) to 
*_compile_warnings:


add_compile_warnings(DISABLE warn-A)
target_compile_warnings(foo DISABLE warn-B IGNORE DIRECTORY)

COMPILE_WARNINGS of target 'foo' property value (warn-A from directory 
properties ignored):


warn-B=off

Same with IGNORE TARGET:

add_compile_warnings(ENABLE warn-A)
target_compile_warnings(foo ENABLE warn-B)
source_files_compile_warnings(foo.cpp ENABLE warn-C IGNORE TARGET)

COMPILE_WARNINGS of 'foo.cpp' property value (warn-B from target 
ignored, directory not):


warn-C=on warn-A=on

Ignoring both:

add_compile_warnings(ENABLE warn-A)
target_compile_warnings(foo ENABLE warn-B)
source_files_compile_warnings(foo.cpp ENABLE warn-C IGNORE TARGET 
DIRECTORY)


Result:

warn-C=on




 may expand to nothing in case warning make no sense for
current language or warning not implemented by compiler:

Okay.


After this feature implemented we need to introduce new policy to avoid
adding warnings flags to CMAKE_CXX_FLAGS by default (e.g. "/W3" added by
default for Visual Studio).

Yes.


Warnings should not be propagated via INTERFACE because unlike
definitions or other compiler flags they doesn't affect final binary or
compatibility.

Okay.


On 29-Mar-16 22:42, Ruslan Baratov wrote:

One more note. Properties is a good abstraction and works great for
the native CMake project. But there is a tricky scenario about them -
when we need to create ExternalProject_Add for the non-CMake project.

Would be nice to have this one.

This is beyond the scope of this change and affects all flags, so
let's defer this for a later time.


Is it possible in general to control warnings globally? Imagine I have
target that should ignore all warnings for any reason. If you able to
control warnings globally this target will generate tons of useless
messages. How to enable warnings for all targets except this one?

This thread has not yet designed any means for a user to control
warnings globally (e.g. via a 

[Cmake-commits] CMake branch, master, updated. v3.5.2-506-g38d1c67

2016-04-22 Thread Kitware Robot
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  38d1c67c4dc03d1365da8b3334d708ed75cfa93a (commit)
  from  eadc6db82e62ac059c9ca6cbbde5f8b31d862f2e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=38d1c67c4dc03d1365da8b3334d708ed75cfa93a
commit 38d1c67c4dc03d1365da8b3334d708ed75cfa93a
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Sat Apr 23 00:01:05 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Sat Apr 23 00:01:05 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index d066f87..2c4b3aa 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 5)
-set(CMake_VERSION_PATCH 20160422)
+set(CMake_VERSION_PATCH 20160423)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


Re: [CMake] Using Clang + Ninja on Windows?

2016-04-22 Thread Edward Diener

On 4/22/2016 4:51 AM, Mueller-Roemer, Johannes Sebastian wrote:

It is true that there is no official bundled installer with both, but
the official installer works just fine with mingw as long as you pass in
the correct target to clang(++)

For example

clang++ --target=x86_64-w64-mingw32 test.cpp

However, it assumes that mingw64 is installed under C:/mingw64 (the
default location, it’ll work with a junction point though).


As of clang 3.7 there is no need to have a hardcoded mingw directory. 
You just need to have an appropriate mingw(-64)/gcc in your PATH. Also 
all distributed versions of clang 3.4 through 3.7 for Windows default to 
targeting mingw(-64)/gcc and not VC++. Only with 3.8 is the Windows 
release defaulting to targeting VC++.



--

Powered by www.kitware.com

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

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

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


[cmake-developers] [CMake 0016077]: FindProtobuf.cmake doesn't have required flexibility to configure protoc usage for all use cases

2016-04-22 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16077 
== 
Reported By:skebanga
Assigned To:
== 
Project:CMake
Issue ID:   16077
Category:   Modules
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-04-22 17:09 EDT
Last Modified:  2016-04-22 17:09 EDT
== 
Summary:FindProtobuf.cmake doesn't have required flexibility
to configure protoc usage for all use cases
Description: 
I have here a very simple test project which has 2 protobuf files, one of which
is included in the other.

Using cmake, I will create a static library for each generated protobuf message.

##Protobuf files:

**`src/foo/message.proto`:**

package test.foo;

message FooMsg
{
required string s = 1;
}

**`src/bar/message.proto`:**

package test.bar;
import "foo/message.proto";

message BarMsg
{
optional foo.FooMsg f = 1;
}

##CMake files:

I build `lib_foo` from generated `foo/message.proto` files.

**`src/foo/CMakeLists.txt`:**

protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS message.proto)

add_library(lib_foo STATIC ${PROTO_SRCS})

I build `lib_bar` from the generated `bar/message.proto` files, and link in
`lib_foo`:

**`src/bar/CMakeLists.txt`:**

protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS message.proto )

add_library(lib_bar STATIC ${PROTO_SRCS})

target_link_libraries(lib_bar lib_foo)

**`src/CMakeLists.txt`:**

cmake_minimum_required (VERSION 3.5)
project (cmake_proto_test CXX)

find_package(Protobuf REQUIRED)

# proto files import from the source root directory, so add the required -I
flag
set(PROTOBUF_IMPORT_DIRS ${CMAKE_SOURCE_DIR})

# genererated proto files go into the CMake binary output dir
include_directories("${CMAKE_BINARY_DIR}")

add_subdirectory(foo)
add_subdirectory(bar)

##Build error:

When I try to build this, I get the following error:

$ make .. VERBOSE=1
cd src/cmake_proto/build/bar && /usr/bin/c++
-I src/cmake_proto/build   
-o CMakeFiles/lib_bar.dir/message.pb.cc.o 
-c src/cmake_proto/build/bar/message.pb.cc

In file included from src/cmake_proto/build/bar/message.pb.cc:5:0:

src/cmake_proto/build/bar/message.pb.h:99:24: 
error: ‘foo’ in namespace ‘test’ does not name a type

   inline const ::test::foo::FooMsg& f() const;
^

##Reason:

The error is due to the header guard created by `protoc` being the same for the
2 generated files:

#ifndef PROTOBUF_message_2eproto__INCLUDED
#define PROTOBUF_message_2eproto__INCLUDED

...

#endif

The reason is that the header guard is derived from a combination of the output
directory and the generated file's path.

The current command issued by `FindProtobuf.cmake` results in the header guard
only using the filename:

cd src/cmake_proto/build/foo && /usr/local/bin/protoc --cpp_out
src/cmake_proto/build/foo -I src/cmake_proto/foo -I src/cmake_proto
src/cmake_proto/foo/message.proto
cd src/cmake_proto/build/bar && /usr/local/bin/protoc --cpp_out
src/cmake_proto/build/bar -I src/cmake_proto/bar -I src/cmake_proto
src/cmake_proto/bar/message.proto

This command, however, will result in the files being generated in the same
location, but with a different header guard:

cd src/cmake_proto/build && /usr/local/bin/protoc --cpp_out
src/cmake_proto/build -I src/cmake_proto src/cmake_proto/foo/message.proto
cd src/cmake_proto/build && /usr/local/bin/protoc --cpp_out
src/cmake_proto/build -I src/cmake_proto src/cmake_proto/bar/message.proto

Header guards:

PROTOBUF_foo_2fmessage_2eproto__INCLUDED
PROTOBUF_bar_2fmessage_2eproto__INCLUDED

There are three key differences here:

- The `WORKING_DIRECTORY` from which `protoc` is run from is
`${CMAKE_BINARY_DIR}`
- The `--cpp_out` directory passed to `protoc` is `${CMAKE_BINARY_DIR}`
- The `-I` include path passed to `protoc` does **not** include the folder where
the proto file is found

Being able to control these 3 items would give the flexibility required to use
this tool in the above setup.


== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-22 17:09 skebanga   New Issue  

Re: [CMake] Finding 32bit libs on 64bit Ubuntu install

2016-04-22 Thread Alan W. Irwin

On 2016-04-22 14:59-0400 Nick Deubert wrote:


Hey everyone, I am trying to build and link some 32bit binaries on
Ubuntu 15.10 64bit, but no matter what combination of arguments I give
FIND_LIBRARY I cannot get it to use the 32bit libs. I have been
scouring the mailing lists and came up with all these things to try
but nothing has worked so far. I am using cmake 3.0.2. Please let me
know what I am missing. Thanks in advance for your help.


CMake 3.0.2 is pretty old, and there were some find and other issues
for early CMake-3 versions.  I don't know whether any of those issues
are relevant to the issue you are discussing. Nevertheless, as an
experiment (and to make sure your eventual solution works for the
latest CMake) I would suggest you try building and using the latest
released version of CMake, 3.5.2, to see if that makes any difference.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

Powered by www.kitware.com

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

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

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

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

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


[CMake] Finding 32bit libs on 64bit Ubuntu install

2016-04-22 Thread Nick Deubert
Hey everyone, I am trying to build and link some 32bit binaries on
Ubuntu 15.10 64bit, but no matter what combination of arguments I give
FIND_LIBRARY I cannot get it to use the 32bit libs. I have been
scouring the mailing lists and came up with all these things to try
but nothing has worked so far. I am using cmake 3.0.2. Please let me
know what I am missing. Thanks in advance for your help.
Nick

The relevant part of my cmake file:

 Set(CFLAGS "-m32")
 Set(CXXFLAGS "-m32")
 Set(CMAKE_C_FLAGS "-m32")
 Set(CMAKE_CXX_FLAGS "-m32")
 Set(CMAKE_SHARED_LINKER_FLAGS "-m32")
 Set(FIND_LIBRARY_USE_LIB64_PATHS OFF)

 MESSAGE( STATUS "CMAKE_LIBRARY_PATH: " ${CMAKE_LIBRARY_PATH} )
 MESSAGE( STATUS "CFLAGS: " ${CFLAGS} )
 MESSAGE( STATUS "CXXFLAGS: " ${CXXFLAGS} )
 MESSAGE( STATUS "CMAKE_C_FLAGS: " ${CMAKE_C_FLAGS} )
 MESSAGE( STATUS "CMAKE_CXX_FLAGS: " ${CMAKE_CXX_FLAGS} )
 MESSAGE( STATUS "CMAKE_SHARED_LINKER_FLAGS: " ${CMAKE_SHARED_LINKER_FLAGS} )
 MESSAGE( STATUS "FIND_LIBRARY_USE_LIB64_PATHS: "
${FIND_LIBRARY_USE_LIB64_PATHS} )

 FIND_LIBRARY(DL_LIBRARY NAMES dl  PATHS  ${LIB_PATH}
NO_DEFAULT_PATH)
 FIND_LIBRARY(NL_LIBRARY NAMES nl  PATHS  ${LIB_PATH}
NO_DEFAULT_PATH)
 FIND_LIBRARY(PTHREAD_LIBRARYNAMES pthread PATHS  ${LIB_PATH}
NO_DEFAULT_PATH)

MESSAGE(STATUS "DL_LIBRARY is ${DL_LIBRARY}")
MESSAGE(STATUS "NL_LIBRARY is ${NL_LIBRARY}")
MESSAGE(STATUS "PTHREAD_LIBRARY is ${PTHREAD_LIBRARY}")

The output I get:

-- CMAKE_LIBRARY_PATH: /lib/i386-linux-gnu
-- CFLAGS: -m32
-- CXXFLAGS: -m32
-- CMAKE_C_FLAGS: -m32
-- CMAKE_CXX_FLAGS: -m32
-- CMAKE_SHARED_LINKER_FLAGS: -m32
-- FIND_LIBRARY_USE_LIB64_PATHS: OFF
-- DL_LIBRARY is DL_LIBRARY-NOTFOUND
-- NL_LIBRARY is NL_LIBRARY-NOTFOUND
-- PTHREAD_LIBRARY is PTHREAD_LIBRARY-NOTFOUND

Without NO_DEFAULT_PATH:

-- DL_LIBRARY is /usr/lib/x86_64-linux-gnu/libdl.so
-- NL_LIBRARY is /lib/x86_64-linux-gnu/libnl.so
-- PTHREAD_LIBRARY is /usr/lib/x86_64-linux-gnu/libpthread.so

Proof that I have the 32bit libs installed:

$ ls -l /lib/i386-linux-gnu/*pthread*
-rwxr-xr-x 1 root root 137044 Feb 16 14:06
/lib/i386-linux-gnu/libpthread-2.21.so*
lrwxrwxrwx 1 root root 18 Feb 16 14:06
/lib/i386-linux-gnu/libpthread.so.0 -> libpthread-2.21.so*
$ ls -l /lib/i386-linux-gnu/*libnl*
-rw-r--r-- 1 root root 165936 Jul 15  2015 /lib/i386-linux-gnu/libnl-3.a
lrwxrwxrwx 1 root root 19 Jul 15  2015
/lib/i386-linux-gnu/libnl-3.so -> libnl-3.so.200.21.0
lrwxrwxrwx 1 root root 19 Jul 15  2015
/lib/i386-linux-gnu/libnl-3.so.200 -> libnl-3.so.200.21.0
-rw-r--r-- 1 root root 132852 Jul 15  2015
/lib/i386-linux-gnu/libnl-3.so.200.21.0
$ ls -l /lib/i386-linux-gnu/*libdl*
-rw-r--r-- 1 root root 13808 Feb 16 14:06 /lib/i386-linux-gnu/libdl-2.21.so
lrwxrwxrwx 1 root root13 Feb 16 14:06
/lib/i386-linux-gnu/libdl.so.2 -> libdl-2.21.so
-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [CMake] How to check if Eclipse CDT4 generated project is set up correctly?

2016-04-22 Thread Martin Weber
Am Freitag, 22. April 2016, 13:28:33 schrieb Nils Rathmann:
> Hi Alex,
> thanks for the details. I managed to add the header files as intended
> and do have the targets you described, but the virtual directories
> "CMake Rules", "Object Files" and "Ressources" of each Target
> subdirectory are still empty. What is the intention of these virtual
> directories?

Hi Nils,

the Eclipse Marketplace has some plugins that help you to work with cmake in 
Eclipse.
Just search for 'cmake'...

Martin

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [CMake] CMake:question of the time when the command will happen in add_custom_command(...)

2016-04-22 Thread Chuck Atkins
Hi Chao,

You can see this more clearly if you do a "make VERBOSE=1" :

[chuck.atkins@hal9000 build]$ make VERBOSE=1
...
[ 50%] Building C object CMakeFiles/main.dir/main.c.o
/usr/bin/cc -o CMakeFiles/main.dir/main.c.o   -c
/home/chuck.atkins/Code/tmp/source/main.c
[100%] Linking C executable main

*echo This\ is\ pre\ build\ This is pre build *
/usr/bin/cmake -E cmake_link_script CMakeFiles/main.dir/link.txt --verbose=1
*/usr/bin/cc CMakeFiles/main.dir/main.c.o  -o main -rdynamic *

*echo This\ is\ post\ buildThis is post build*
make[2]: Leaving directory '/home/chuck.atkins/Code/tmp/build'
[100%] Built target main
make[1]: Leaving directory '/home/chuck.atkins/Code/tmp/build'
/usr/bin/cmake -E cmake_progress_start
/home/chuck.atkins/Code/tmp/build/CMakeFiles 0
[chuck.atkins@hal9000 build]$

Here you can see the order of command execution is PRE_BUILD -> Link ->
POST_BUILD

- Chuck

On Fri, Apr 22, 2016 at 5:53 AM, Chaos Zhang  wrote:

> Sorry for i just know reply by email and thinks for your help again. :-)
>
>
> Petr Kmoch wrote
> > No, it is indeed compiled and linked just fine. What I meant is:
> >
> > Without any custom commands, the build process conceptually looks like
> > this:
> >
> > buildMain() {
> >   compile_object_files();
> >   link_main_binary();
> >
> >   message("Built target main");
> > }
> >
> > With a post-build custom command:
> >
> > buildMain() {
> >   compile_object_files();
> >   link_main_binary();
> >   post_build_command();
> >
> >   message("Built target main");
> > }
> >
> > The custom command becomes a part of the entire process of "Building
> > target," that's why the "Built target" message appears after the command
> > runs.
> >
> > BTW, please keep the mailing list in copy when replying.
> >
> > Petr
> >
> > On 22 April 2016 at 10:02, Chaos Zhang 
>
> > zcsd2012@
>
> >  wrote:
> >
> >> So what you mean is the target have not been complied and linked after i
> >> introduce
> >> custom commands into this target right? Do i understand right?
> >>
> >> Thanks a lot for your generous help. :-)
> >>
> >> 2016-04-22 16:38 GMT+08:00 Petr Kmoch 
>
> > petr.kmoch@
>
> > :
> >>
> >>> Hi,
> >>>
> >>> the reason is that the post-build command is actually a part of
> building
> >>> "main the target." Once you introduce custom commands into a target,
> >>> building it includes them all, and not just compiling the object files
> >>> and
> >>> linking the binary. You will notice that the "Linking C exectuable
> main"
> >>> line came before the post-build message, so it did happen in the
> correct
> >>> order.
> >>>
> >>> Petr
> >>>
> >>> On 22 April 2016 at 06:25, Chaos Zhang 
>
> > zcsd2012@
>
> >  wrote:
> >>>
>  Hi all,
> 
>  I have some trouble when i use PRE_BUILD | PRE_LINK | POST_BUILD in
>  command
>  "add_custom_command(...)". When i use POST_BUILD, i found the command
>  will
>  execute before target had been built, like this:
> 
>  1 [root@VM_33_35_centos build]# make
>  2 Scanning dependencies of target main
>  3 [100%] Building C object CMakeFiles/main.dir/main.c.o
>  4 Linking C executable main
>  5 This is pre build
>  6 This is post build
>  7 [100%] Built target main
> 
>  In my CMakeLists.txt, the content is:
>   1 cmake_minimum_required(VERSION 2.8)
>   2 add_executable(main main.c)
>   3 add_custom_command(TARGET main
>   4 PRE_BUILD
>   5 COMMAND echo "This is pre build "
>   6 )
>   7 add_custom_command(TARGET main
>   8 POST_BUILD
>   9 COMMAND echo "This is post build"
>   10 )
> 
>  Why the command echo "This is post build" in 8 line(CMakeLists.txt)
> did
>  not
>  execute after [100%] Built target main in 7 line(Linux command)?
> 
> 
> 
> 
>  --
>  View this message in context:
> 
> http://cmake.3232098.n2.nabble.com/CMake-question-of-the-time-when-the-command-will-happen-in-add-custom-command-tp7593314.html
>  Sent from the CMake mailing list archive at Nabble.com.
>  --
> 
>  Powered by www.kitware.com
> 
>  Please keep messages on-topic and check the CMake FAQ at:
>  http://www.cmake.org/Wiki/CMake_FAQ
> 
>  Kitware offers various services to support the CMake community. For
>  more
>  information on each offering, please visit:
> 
>  CMake Support: http://cmake.org/cmake/help/support.html
>  CMake Consulting: http://cmake.org/cmake/help/consulting.html
>  CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
>  Visit other Kitware open-source projects at
>  http://www.kitware.com/opensource/opensource.html
> 
>  Follow this link to subscribe/unsubscribe:
>  http://public.kitware.com/mailman/listinfo/cmake
> 
> >>>
> >>>
> >>
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please 

[cmake-developers] [CMake 0016076]: bin install directory configuration

2016-04-22 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16076 
== 
Reported By:blackstar
Assigned To:
== 
Project:CMake
Issue ID:   16076
Category:   CMakeSetup
Reproducibility:always
Severity:   block
Priority:   normal
Status: new
== 
Date Submitted: 2016-04-22 10:39 EDT
Last Modified:  2016-04-22 10:39 EDT
== 
Summary:bin install directory configuration
Description: 
It is impossible to set the CMake bin install directory with bootstrap options.
The bin install directory is always /bin.
If cmake binary is moved to other location, The CMAKE_ROOT could not be find,
because the unique search directory of /Modules/CMake.cmake file is at the same
level of bin directory.

CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in

So it is impossible to have in the same install directory, several CMake binary
of different OS.
For example :
   cmake-3.5.2/bin/centos6.2/cmake
   cmake-3.5.2/bin/ubuntu14.04/cmake

Is it possible to add an option in bootstrap, like --docdir, to set the binary
install directory relative to  ?

Steps to Reproduce: 
do a cmake installation
move the cmake binary
run cmake
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-22 10:39 blackstar  New Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] Autogen subdirectories patches

2016-04-22 Thread Brad King
On 04/21/2016 03:14 AM, Sebastian Holtermann wrote:
>> Thanks!  I've applied them locally and merged the cleanup/refactoring
>> commits to 'next' for testing first.  Once those test cleanly I'll move
>> on to the rest.
> 
> It is good too see the patches made it into the next branch.

The rest of the changes are now in 'master'.  Thanks for working on this!

> Now there is another issue I have a partially fix for.
> 
> As of now all included mocs and uis get generated in
> CMAKE_CURRENT_BINARY_DIR/
> because they must be within INCLUDE_DIRECTORIES.
> I think a more robust approach would be to generate them in
> CMAKE_CURRENT_BINARY_DIR/TARGET_automoc.dir/
> and to add the _automoc.dir to INCLUDE_DIRECTORIES.
> 
> I've attached a patch that does does so
> - it is relative to current "next" branch.

You should be able to rebase on 'master' now.

> It is incomplete though because I didn't manage to get
> CMAKE_CURRENT_BINARY_DIR/TARGET_automoc.dir/
> into INCLUDE_DIRECTORIES in Source/cmQtAutoGeneratorInitializer.cxx.
> (GetAutogenTargetBuildDir() in Source/cmQtAutoGeneratorInitializer.cxx)
> 
> If someone could do that or give me pointers on how to do it
> then this could be another improvement.

I'm afraid I'm not familiar enough with this infrastructure to know
for sure.  The entire Qt autogen infrastructure was built by others.
Take a look at cmGlobalGenerator::Compute to see a carefully
ordered set of operations.  Among them is the QtAutoGenerator step.
I'm not sure of its order relative to INCLUDE_DIRECTORIES evaluation.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] CMake API for warnings

2016-04-22 Thread Brad King
On 04/20/2016 09:50 AM, Ruslan Baratov wrote:
> 1) add_compile_warnings
>* similar to add_definitions, add_compile_options
>* modify COMPILE_WARNINGS directory property (append)
> 2) target_compile_warnings
>* similar to target_compile_options, target_compile_definitions
>* modify COMPILE_WARNINGS target property (append)
> 3) source_files_compile_warnings
>* similar to set_source_files_properties
>* modify COMPILE_WARNINGS sources property (append)

Sounds good.  Note that cmTarget has dedicated storage with backtrace
information for other build system properties.  Please use the same
pattern for these.  I also suggest getting the directory/target level
working first and work on source files later.  The infrastructure for
the latter is not as mature so it may need more work.

>*_compile_warnings(
>
>DISABLE  # add =off to COMPILE_WARNINGS 
> property
>ENABLE  # add =on to COMPILE_WARNINGS 
> property
>TREAT_AS_ERROR  # add =error to 
> COMPILE_WARNINGS property
>)

Sounds good.

>* all (compiler specific "all", e.g. /Wall or -Wall)
>* default
>* level
>* none
>* everything (all possible warnings for compiler, if there is no such 
> option use maximum level plus some warnings explicitly)

Okay.  Let's drop level for now for the reason you outlined.
We can always add it later.

> Properties will be set in form =on|off|error, e.g.:
> 
>add_compile_warnings(DISABLE undef unused ENABLE inline TREAT_AS_ERROR 
> everything)
> 
> will set COMPILE_WARNINGS directory property to:
> 
>undef=off unused=off inline=on everything=error

Good.

> In case of any conflicts return CMake warning for developer message 
> (cmake -Wdev/cmake -Wno-dev).

Good.

>Directory properties affect targets and sources, target properties 
> affect sources of this target. E.g.:
> 
>  add_compile_warnings(DISABLE undef)
>  target_compile_warnings(foo DISABLE unused)
> 
>effectively equivalent to:
> 
>  target_compile_warnings(foo DISABLE undef unused)
> 
>Question: do we need to control this? probably by 
> 'target_compile_warnings(foo DISABLE unused IGNORE DIRECTORY)' ?

It should be possible to merge the directory/target/source settings
with proper precedence.  I don't understand your example well enough
to see what "IGNORE DIRECTORY" would mean.  Either way, such information
needs to be encoded somehow in the property values.

> may expand to nothing in case warning make no sense for 
> current language or warning not implemented by compiler:

Okay.

> After this feature implemented we need to introduce new policy to avoid 
> adding warnings flags to CMAKE_CXX_FLAGS by default (e.g. "/W3" added by 
> default for Visual Studio).

Yes.

> Warnings should not be propagated via INTERFACE because unlike 
> definitions or other compiler flags they doesn't affect final binary or 
> compatibility.

Okay.

> On 29-Mar-16 22:42, Ruslan Baratov wrote:
>> One more note. Properties is a good abstraction and works great for 
>> the native CMake project. But there is a tricky scenario about them - 
>> when we need to create ExternalProject_Add for the non-CMake project.
> 
> Would be nice to have this one.

This is beyond the scope of this change and affects all flags, so
let's defer this for a later time.

> Is it possible in general to control warnings globally? Imagine I have 
> target that should ignore all warnings for any reason. If you able to 
> control warnings globally this target will generate tons of useless 
> messages. How to enable warnings for all targets except this one?

This thread has not yet designed any means for a user to control
warnings globally (e.g. via a cache entry).  Project code should
be able to offer such options manually, but it would also be nice
to have a CMake-defined setting.  The semantics of such a setting
will need to be defined carefully to allow the project to override
(or not override) settings for specific targets.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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


[Cmake-commits] CMake branch, next, updated. v3.5.2-1076-g824dc08

2016-04-22 Thread Brad King
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  824dc081274b1e535b1cddeb438370e4f52b7785 (commit)
   via  eadc6db82e62ac059c9ca6cbbde5f8b31d862f2e (commit)
   via  76e793b9ad1483f6f397f630fdc5d4fcaf141c06 (commit)
   via  eb87407068070d38dbac06a1542b9c3e63ce7fa7 (commit)
   via  e5a9a437fb5c6c634a970a0eb78271147bb2f95c (commit)
   via  02f663f15c173bf61147771076b7f822b0a8eb7c (commit)
   via  9b5929da22bc521602b547be945c2252496ecf01 (commit)
  from  3cd8011d1576a9fb028d34b2789178d2326f6b5b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=824dc081274b1e535b1cddeb438370e4f52b7785
commit 824dc081274b1e535b1cddeb438370e4f52b7785
Merge: 3cd8011 eadc6db
Author: Brad King 
AuthorDate: Fri Apr 22 09:05:16 2016 -0400
Commit: Brad King 
CommitDate: Fri Apr 22 09:05:16 2016 -0400

Merge branch 'master' into next


---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, master, updated. v3.5.2-505-geadc6db

2016-04-22 Thread Brad King
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  eadc6db82e62ac059c9ca6cbbde5f8b31d862f2e (commit)
   via  fd73bb601a629ce09868d3d7068272b3bd3870c3 (commit)
   via  f56a0ddd289827b5daca473b6a3e46efa5c8f15b (commit)
   via  3d13492eac641f755ad13291560b91113c2a61d9 (commit)
  from  76e793b9ad1483f6f397f630fdc5d4fcaf141c06 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eadc6db82e62ac059c9ca6cbbde5f8b31d862f2e
commit eadc6db82e62ac059c9ca6cbbde5f8b31d862f2e
Merge: 76e793b fd73bb6
Author: Brad King 
AuthorDate: Fri Apr 22 09:02:08 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Apr 22 09:02:08 2016 -0400

Merge topic 'fix-bison-flex-command-escaping'

fd73bb60 Help: Add notes for topic 'fix-bison-flex-command-escaping'
f56a0ddd FindBISON: Fix BISON_TARGET macro for special characters in path 
(#16072)
3d13492e FindFLEX: Fix FLEX_TARGET macro for special characters in path 
(#16072)


---

Summary of changes:
 Help/release/dev/fix-bison-flex-command-escaping.rst |   12 
 Modules/FindBISON.cmake  |8 
 Modules/FindFLEX.cmake   |4 ++--
 3 files changed, 18 insertions(+), 6 deletions(-)
 create mode 100644 Help/release/dev/fix-bison-flex-command-escaping.rst


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, master, updated. v3.5.2-501-g76e793b

2016-04-22 Thread Brad King
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  76e793b9ad1483f6f397f630fdc5d4fcaf141c06 (commit)
   via  84946c735cc6d2b8f8e014f4772dd602b4a83a16 (commit)
   via  9c6fa684e7681417f5e75f25034f28212e22b229 (commit)
   via  488ea8c7093849cc60ae0e99ef883b2ddacfdf86 (commit)
   via  66caae45f615e03c49a87cb17901fd89ffd389af (commit)
   via  663d093d454902269a83d7f07c6546e773328086 (commit)
   via  8295d43713b621558ce8fc67033021e6eb2a6612 (commit)
   via  d350308af6704e70f94ef00d45c4b52ad779e566 (commit)
  from  eb87407068070d38dbac06a1542b9c3e63ce7fa7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76e793b9ad1483f6f397f630fdc5d4fcaf141c06
commit 76e793b9ad1483f6f397f630fdc5d4fcaf141c06
Merge: eb87407 84946c7
Author: Brad King 
AuthorDate: Fri Apr 22 09:02:03 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Apr 22 09:02:03 2016 -0400

Merge topic 'autogen-updates'

84946c73 Tests: QtAutogen: Same source name in different directories test
9c6fa684 Autogen: Generate qrc_NAME.cpp files in subdirectories
488ea8c7 Autogen: Generate not included moc files in subdirectories (#12873)
66caae45 Autogen: Check added for name collisions of generated qrc_NAME.cpp 
files
663d093d Autogen: Check added for name collisions of generated ui_NAME.h 
files
8295d437 Autogen: Check added for name collisions of generated moc files
d350308a Help: Improve AUTOMOC documentation layout


---

Summary of changes:
 Help/prop_tgt/AUTOMOC.rst  |   45 ---
 Help/release/dev/automoc-diagnostics.rst   |6 +
 Source/cmQtAutoGeneratorInitializer.cxx|  130 +++-
 Source/cmQtAutoGenerators.cxx  |  183 +---
 Source/cmQtAutoGenerators.h|   10 +-
 Tests/QtAutogen/CMakeLists.txt |4 +
 Tests/QtAutogen/same_name/CMakeLists.txt   |   20 +++
 Tests/QtAutogen/same_name/aaa/bbb/data.qrc |6 +
 Tests/QtAutogen/same_name/aaa/bbb/item.cpp |   12 ++
 Tests/QtAutogen/same_name/aaa/bbb/item.hpp |   19 +++
 Tests/QtAutogen/same_name/aaa/data.qrc |6 +
 Tests/QtAutogen/same_name/aaa/item.cpp |   10 ++
 Tests/QtAutogen/same_name/aaa/item.hpp |   17 +++
 Tests/QtAutogen/same_name/bbb/aaa/data.qrc |6 +
 Tests/QtAutogen/same_name/bbb/aaa/item.cpp |   12 ++
 Tests/QtAutogen/same_name/bbb/aaa/item.hpp |   19 +++
 Tests/QtAutogen/same_name/bbb/data.qrc |6 +
 Tests/QtAutogen/same_name/bbb/item.cpp |   10 ++
 Tests/QtAutogen/same_name/bbb/item.hpp |   17 +++
 Tests/QtAutogen/same_name/ccc/data.qrc |6 +
 Tests/QtAutogen/same_name/ccc/item.cpp |   26 
 Tests/QtAutogen/same_name/ccc/item.hpp |   17 +++
 Tests/QtAutogen/same_name/data.qrc |5 +
 Tests/QtAutogen/same_name/main.cpp |   16 +++
 24 files changed, 545 insertions(+), 63 deletions(-)
 create mode 100644 Help/release/dev/automoc-diagnostics.rst
 create mode 100644 Tests/QtAutogen/same_name/CMakeLists.txt
 create mode 100644 Tests/QtAutogen/same_name/aaa/bbb/data.qrc
 create mode 100644 Tests/QtAutogen/same_name/aaa/bbb/item.cpp
 create mode 100644 Tests/QtAutogen/same_name/aaa/bbb/item.hpp
 create mode 100644 Tests/QtAutogen/same_name/aaa/data.qrc
 create mode 100644 Tests/QtAutogen/same_name/aaa/item.cpp
 create mode 100644 Tests/QtAutogen/same_name/aaa/item.hpp
 create mode 100644 Tests/QtAutogen/same_name/bbb/aaa/data.qrc
 create mode 100644 Tests/QtAutogen/same_name/bbb/aaa/item.cpp
 create mode 100644 Tests/QtAutogen/same_name/bbb/aaa/item.hpp
 create mode 100644 Tests/QtAutogen/same_name/bbb/data.qrc
 create mode 100644 Tests/QtAutogen/same_name/bbb/item.cpp
 create mode 100644 Tests/QtAutogen/same_name/bbb/item.hpp
 create mode 100644 Tests/QtAutogen/same_name/ccc/data.qrc
 create mode 100644 Tests/QtAutogen/same_name/ccc/item.cpp
 create mode 100644 Tests/QtAutogen/same_name/ccc/item.hpp
 create mode 100644 Tests/QtAutogen/same_name/data.qrc
 create mode 100644 Tests/QtAutogen/same_name/main.cpp


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, master, updated. v3.5.2-493-geb87407

2016-04-22 Thread Brad King
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  eb87407068070d38dbac06a1542b9c3e63ce7fa7 (commit)
   via  2263949b7817fad0b2560cb5dd8e102d1f547b47 (commit)
   via  2b25ce30ca825765a5c249e455c466802af95116 (commit)
   via  ffedf3527d7e714b6885b822ee85889016418ebb (commit)
   via  6100bdff38580d297c098127e9bc0105b7a33e06 (commit)
  from  e5a9a437fb5c6c634a970a0eb78271147bb2f95c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eb87407068070d38dbac06a1542b9c3e63ce7fa7
commit eb87407068070d38dbac06a1542b9c3e63ce7fa7
Merge: e5a9a43 2263949
Author: Brad King 
AuthorDate: Fri Apr 22 09:01:33 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Apr 22 09:01:33 2016 -0400

Merge topic 'xcode-c_str'

2263949b cmGlobalXCodeGenerator: do not pass char* to 
cmSystemTools::CollapseFullPath()
2b25ce30 make cmGlobalXCodeGenerator::XCodeEscapePath() take a std::string&
ffedf352 make cmGlobalXCodeGenerator::BuildObjectListOrString::Add() take a 
string&
6100bdff cmGlobalXCodeGenerator: directly call CreateString() with 
std::string


---

Summary of changes:
 Source/cmGlobalXCodeGenerator.cxx |  107 ++---
 Source/cmGlobalXCodeGenerator.h   |2 +-
 2 files changed, 54 insertions(+), 55 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, master, updated. v3.5.2-488-ge5a9a43

2016-04-22 Thread Brad King
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  e5a9a437fb5c6c634a970a0eb78271147bb2f95c (commit)
   via  068358e1edd4ed0c19a40f3be16edb64123f45ee (commit)
  from  02f663f15c173bf61147771076b7f822b0a8eb7c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e5a9a437fb5c6c634a970a0eb78271147bb2f95c
commit e5a9a437fb5c6c634a970a0eb78271147bb2f95c
Merge: 02f663f 068358e
Author: Brad King 
AuthorDate: Fri Apr 22 09:01:22 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Apr 22 09:01:22 2016 -0400

Merge topic 'addcachedefinitions-convert'

068358e1 cmMakefile::AddCacheDefinition: avoid conversions between char* 
and string


---

Summary of changes:
 Source/cmMakefile.cxx |   21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[Cmake-commits] CMake branch, next, updated. v3.5.2-1069-g3cd8011

2016-04-22 Thread Brad King
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  3cd8011d1576a9fb028d34b2789178d2326f6b5b (commit)
   via  84946c735cc6d2b8f8e014f4772dd602b4a83a16 (commit)
   via  9c6fa684e7681417f5e75f25034f28212e22b229 (commit)
  from  b58bed802af3c9036296688a2987c9a2d5dcd0ff (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3cd8011d1576a9fb028d34b2789178d2326f6b5b
commit 3cd8011d1576a9fb028d34b2789178d2326f6b5b
Merge: b58bed8 84946c7
Author: Brad King 
AuthorDate: Fri Apr 22 08:57:05 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Apr 22 08:57:05 2016 -0400

Merge topic 'autogen-updates' into next

84946c73 Tests: QtAutogen: Same source name in different directories test
9c6fa684 Autogen: Generate qrc_NAME.cpp files in subdirectories


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=84946c735cc6d2b8f8e014f4772dd602b4a83a16
commit 84946c735cc6d2b8f8e014f4772dd602b4a83a16
Author: Sebastian Holtermann 
AuthorDate: Wed Apr 13 18:36:39 2016 +0200
Commit: Brad King 
CommitDate: Fri Apr 22 08:55:44 2016 -0400

Tests: QtAutogen: Same source name in different directories test

The test features multiple .cpp and .qrc files with the same name
in different subdirectories. This requires AUTOMOC and AUTORCC to
generate files with names that respect the path information of
the source files.

diff --git a/Tests/QtAutogen/CMakeLists.txt b/Tests/QtAutogen/CMakeLists.txt
index d5aca55..4875165 100644
--- a/Tests/QtAutogen/CMakeLists.txt
+++ b/Tests/QtAutogen/CMakeLists.txt
@@ -110,6 +110,10 @@ set_target_properties(
   AUTOMOC TRUE
 )
 
+# Test AUTOMOC and AUTORCC on source files with the same name
+# but in different subdirectories
+add_subdirectory(same_name)
+
 include(GenerateExportHeader)
 # The order is relevant here. B depends on A, and B headers depend on A
 # headers both subdirectories use CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE and we
diff --git a/Tests/QtAutogen/same_name/CMakeLists.txt 
b/Tests/QtAutogen/same_name/CMakeLists.txt
new file mode 100644
index 000..54bf048
--- /dev/null
+++ b/Tests/QtAutogen/same_name/CMakeLists.txt
@@ -0,0 +1,20 @@
+# Test AUTOMOC and AUTORCC on source files with the same name
+# but in different subdirectories
+
+add_executable(same_name
+  aaa/bbb/item.cpp
+  aaa/bbb/data.qrc
+  aaa/item.cpp
+  aaa/data.qrc
+  bbb/aaa/item.cpp
+  bbb/aaa/data.qrc
+  bbb/item.cpp
+  bbb/data.qrc
+  ccc/item.cpp
+  ccc/data.qrc
+  main.cpp
+  data.qrc
+)
+target_include_directories(same_name PRIVATE ${CMAKE_CURRENT_BINARY_DIR})
+target_link_libraries(same_name ${QT_LIBRARIES})
+set_target_properties( same_name PROPERTIES AUTOMOC TRUE AUTORCC TRUE )
diff --git a/Tests/QtAutogen/same_name/aaa/bbb/data.qrc 
b/Tests/QtAutogen/same_name/aaa/bbb/data.qrc
new file mode 100644
index 000..0ea3537
--- /dev/null
+++ b/Tests/QtAutogen/same_name/aaa/bbb/data.qrc
@@ -0,0 +1,6 @@
+
+
+  item.hpp
+  item.cpp
+
+
diff --git a/Tests/QtAutogen/same_name/aaa/bbb/item.cpp 
b/Tests/QtAutogen/same_name/aaa/bbb/item.cpp
new file mode 100644
index 000..d715116
--- /dev/null
+++ b/Tests/QtAutogen/same_name/aaa/bbb/item.cpp
@@ -0,0 +1,12 @@
+#include "item.hpp"
+
+namespace aaa {
+namespace bbb {
+
+void
+Item::go ( )
+{
+}
+
+}
+}
diff --git a/Tests/QtAutogen/same_name/aaa/bbb/item.hpp 
b/Tests/QtAutogen/same_name/aaa/bbb/item.hpp
new file mode 100644
index 000..c82309d
--- /dev/null
+++ b/Tests/QtAutogen/same_name/aaa/bbb/item.hpp
@@ -0,0 +1,19 @@
+#ifndef SDA_SDB_ITEM_HPP
+#define SDA_SDB_ITEM_HPP
+
+#include 
+
+namespace aaa {
+namespace bbb {
+
+class Item : public QObject
+{
+  Q_OBJECT
+  Q_SLOT
+  void go ( );
+};
+
+}
+}
+
+#endif
diff --git a/Tests/QtAutogen/same_name/aaa/data.qrc 
b/Tests/QtAutogen/same_name/aaa/data.qrc
new file mode 100644
index 000..379af60
--- /dev/null
+++ b/Tests/QtAutogen/same_name/aaa/data.qrc
@@ -0,0 +1,6 @@
+
+
+  item.hpp
+  item.cpp
+
+
diff --git a/Tests/QtAutogen/same_name/aaa/item.cpp 
b/Tests/QtAutogen/same_name/aaa/item.cpp
new file mode 100644
index 000..7887d76
--- /dev/null
+++ b/Tests/QtAutogen/same_name/aaa/item.cpp
@@ -0,0 +1,10 @@
+#include "item.hpp"
+
+namespace aaa {
+
+void
+Item::go ( )
+{
+}
+
+}
diff --git a/Tests/QtAutogen/same_name/aaa/item.hpp 
b/Tests/QtAutogen/same_name/aaa/item.hpp
new file mode 100644
index 000..3c24275
--- /dev/null
+++ b/Tests/QtAutogen/same_name/aaa/item.hpp
@@ -0,0 +1,17 @@
+#ifndef SDA_ITEM_HPP
+#define SDA_ITEM_HPP
+
+#include 
+
+namespace aaa {
+
+class Item : 

[Cmake-commits] CMake branch, next, updated. v3.5.2-1066-gb58bed8

2016-04-22 Thread Brad King
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  b58bed802af3c9036296688a2987c9a2d5dcd0ff (commit)
   via  fde84b25e928399ff7e96bd94c1f5acfd5dc1508 (commit)
   via  57d0ec0199c32db88487d3cee886f9fc15034ff2 (commit)
   via  488ea8c7093849cc60ae0e99ef883b2ddacfdf86 (commit)
   via  66caae45f615e03c49a87cb17901fd89ffd389af (commit)
   via  663d093d454902269a83d7f07c6546e773328086 (commit)
   via  8295d43713b621558ce8fc67033021e6eb2a6612 (commit)
   via  d350308af6704e70f94ef00d45c4b52ad779e566 (commit)
  from  f7eb7745dd8ed7b08a8456059a84a99ac3f0354e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b58bed802af3c9036296688a2987c9a2d5dcd0ff
commit b58bed802af3c9036296688a2987c9a2d5dcd0ff
Merge: f7eb774 fde84b2
Author: Brad King 
AuthorDate: Fri Apr 22 08:51:30 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Fri Apr 22 08:51:30 2016 -0400

Merge topic 'autogen-updates' into next

fde84b25 Tests: QtAutogen: Same source name in different directories test
57d0ec01 Autogen: Generate qrc_NAME.cpp files in subdirectories (#16068)
488ea8c7 Autogen: Generate not included moc files in subdirectories (#12873)
66caae45 Autogen: Check added for name collisions of generated qrc_NAME.cpp 
files
663d093d Autogen: Check added for name collisions of generated ui_NAME.h 
files
8295d437 Autogen: Check added for name collisions of generated moc files
d350308a Help: Improve AUTOMOC documentation layout


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fde84b25e928399ff7e96bd94c1f5acfd5dc1508
commit fde84b25e928399ff7e96bd94c1f5acfd5dc1508
Author: Sebastian Holtermann 
AuthorDate: Wed Apr 13 18:36:39 2016 +0200
Commit: Brad King 
CommitDate: Fri Apr 22 08:49:22 2016 -0400

Tests: QtAutogen: Same source name in different directories test

The test features multiple .cpp and .qrc files with the same name
in different subdirectories. This requires AUTOMOC and AUTORCC to
generate files with names that respect the path information of
the source files.

diff --git a/Tests/QtAutogen/CMakeLists.txt b/Tests/QtAutogen/CMakeLists.txt
index d5aca55..4875165 100644
--- a/Tests/QtAutogen/CMakeLists.txt
+++ b/Tests/QtAutogen/CMakeLists.txt
@@ -110,6 +110,10 @@ set_target_properties(
   AUTOMOC TRUE
 )
 
+# Test AUTOMOC and AUTORCC on source files with the same name
+# but in different subdirectories
+add_subdirectory(same_name)
+
 include(GenerateExportHeader)
 # The order is relevant here. B depends on A, and B headers depend on A
 # headers both subdirectories use CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE and we
diff --git a/Tests/QtAutogen/same_name/CMakeLists.txt 
b/Tests/QtAutogen/same_name/CMakeLists.txt
new file mode 100644
index 000..54bf048
--- /dev/null
+++ b/Tests/QtAutogen/same_name/CMakeLists.txt
@@ -0,0 +1,20 @@
+# Test AUTOMOC and AUTORCC on source files with the same name
+# but in different subdirectories
+
+add_executable(same_name
+  aaa/bbb/item.cpp
+  aaa/bbb/data.qrc
+  aaa/item.cpp
+  aaa/data.qrc
+  bbb/aaa/item.cpp
+  bbb/aaa/data.qrc
+  bbb/item.cpp
+  bbb/data.qrc
+  ccc/item.cpp
+  ccc/data.qrc
+  main.cpp
+  data.qrc
+)
+target_include_directories(same_name PRIVATE ${CMAKE_CURRENT_BINARY_DIR})
+target_link_libraries(same_name ${QT_LIBRARIES})
+set_target_properties( same_name PROPERTIES AUTOMOC TRUE AUTORCC TRUE )
diff --git a/Tests/QtAutogen/same_name/aaa/bbb/data.qrc 
b/Tests/QtAutogen/same_name/aaa/bbb/data.qrc
new file mode 100644
index 000..0ea3537
--- /dev/null
+++ b/Tests/QtAutogen/same_name/aaa/bbb/data.qrc
@@ -0,0 +1,6 @@
+
+
+  item.hpp
+  item.cpp
+
+
diff --git a/Tests/QtAutogen/same_name/aaa/bbb/item.cpp 
b/Tests/QtAutogen/same_name/aaa/bbb/item.cpp
new file mode 100644
index 000..d715116
--- /dev/null
+++ b/Tests/QtAutogen/same_name/aaa/bbb/item.cpp
@@ -0,0 +1,12 @@
+#include "item.hpp"
+
+namespace aaa {
+namespace bbb {
+
+void
+Item::go ( )
+{
+}
+
+}
+}
diff --git a/Tests/QtAutogen/same_name/aaa/bbb/item.hpp 
b/Tests/QtAutogen/same_name/aaa/bbb/item.hpp
new file mode 100644
index 000..c82309d
--- /dev/null
+++ b/Tests/QtAutogen/same_name/aaa/bbb/item.hpp
@@ -0,0 +1,19 @@
+#ifndef SDA_SDB_ITEM_HPP
+#define SDA_SDB_ITEM_HPP
+
+#include 
+
+namespace aaa {
+namespace bbb {
+
+class Item : public QObject
+{
+  Q_OBJECT
+  Q_SLOT
+  void go ( );
+};
+
+}
+}
+
+#endif
diff --git a/Tests/QtAutogen/same_name/aaa/data.qrc 
b/Tests/QtAutogen/same_name/aaa/data.qrc
new file mode 100644
index 

Re: [CMake] How to check if Eclipse CDT4 generated project is set up correctly?

2016-04-22 Thread Nils Rathmann

Hi Alex,
thanks for the details. I managed to add the header files as intended 
and do have the targets you described, but the virtual directories 
"CMake Rules", "Object Files" and "Ressources" of each Target 
subdirectory are still empty. What is the intention of these virtual 
directories?


Thank you,
Nils


Am 20.04.2016 um 22:14 schrieb Alexander Neundorf:

On Monday, April 18, 2016 16:57:52 Nils Rathmann wrote:

Hi,
when I setup with the Eclipse CDT4 generator, as described here:
https://cmake.org/Wiki/Eclipse_CDT4_Generator4

my [Targets] folder contains virtual folders for CMakeRules, Header
Files, Object Files, Resources and Source Files,

Yes, those are the standard groups created by cmake.


but only the source files folder is filled.

If you list also the header files in the sources for a target, they will
appear in the [Header Files] group.


The other folders are always empty, even if I
build the target or the whole project. Is there a documentation where I
can see how a generated Eclipse project should look like? When I compare
my project with the sample screenshot in the wiki linked above, it looks
totally different (mine has a lot of virtual folders like Subprojects,
Targets, ...)

you should have a [Source directory] virtual folder pointing to
${CMAKE_SOURCE_DIR}.
You should have a virtual folder [Subprojects], with one subdir for every
project()-call in your project.

The "Make targets" tab should have some global targets to  build (like all,
clean, rebuild_cache) and a "Build" and "Clean" make target for every target.

Is this so ?

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


Re: [CMake] CMake:question of the time when the command will happen in add_custom_command(...)

2016-04-22 Thread Chaos Zhang
Sorry for i just know reply by email and thinks for your help again. :-)


Petr Kmoch wrote
> No, it is indeed compiled and linked just fine. What I meant is:
> 
> Without any custom commands, the build process conceptually looks like
> this:
> 
> buildMain() {
>   compile_object_files();
>   link_main_binary();
> 
>   message("Built target main");
> }
> 
> With a post-build custom command:
> 
> buildMain() {
>   compile_object_files();
>   link_main_binary();
>   post_build_command();
> 
>   message("Built target main");
> }
> 
> The custom command becomes a part of the entire process of "Building
> target," that's why the "Built target" message appears after the command
> runs.
> 
> BTW, please keep the mailing list in copy when replying.
> 
> Petr
> 
> On 22 April 2016 at 10:02, Chaos Zhang 

> zcsd2012@

>  wrote:
> 
>> So what you mean is the target have not been complied and linked after i
>> introduce
>> custom commands into this target right? Do i understand right?
>>
>> Thanks a lot for your generous help. :-)
>>
>> 2016-04-22 16:38 GMT+08:00 Petr Kmoch 

> petr.kmoch@

> :
>>
>>> Hi,
>>>
>>> the reason is that the post-build command is actually a part of building
>>> "main the target." Once you introduce custom commands into a target,
>>> building it includes them all, and not just compiling the object files
>>> and
>>> linking the binary. You will notice that the "Linking C exectuable main"
>>> line came before the post-build message, so it did happen in the correct
>>> order.
>>>
>>> Petr
>>>
>>> On 22 April 2016 at 06:25, Chaos Zhang 

> zcsd2012@

>  wrote:
>>>
 Hi all,

 I have some trouble when i use PRE_BUILD | PRE_LINK | POST_BUILD in
 command
 "add_custom_command(...)". When i use POST_BUILD, i found the command
 will
 execute before target had been built, like this:

 1 [root@VM_33_35_centos build]# make
 2 Scanning dependencies of target main
 3 [100%] Building C object CMakeFiles/main.dir/main.c.o
 4 Linking C executable main
 5 This is pre build
 6 This is post build
 7 [100%] Built target main

 In my CMakeLists.txt, the content is:
  1 cmake_minimum_required(VERSION 2.8)
  2 add_executable(main main.c)
  3 add_custom_command(TARGET main
  4 PRE_BUILD
  5 COMMAND echo "This is pre build "
  6 )
  7 add_custom_command(TARGET main
  8 POST_BUILD
  9 COMMAND echo "This is post build"
  10 )

 Why the command echo "This is post build" in 8 line(CMakeLists.txt) did
 not
 execute after [100%] Built target main in 7 line(Linux command)?




 --
 View this message in context:
 http://cmake.3232098.n2.nabble.com/CMake-question-of-the-time-when-the-command-will-happen-in-add-custom-command-tp7593314.html
 Sent from the CMake mailing list archive at Nabble.com.
 --

 Powered by www.kitware.com

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

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

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

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

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

>>>
>>>
>>
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake





--
View this message in context: 
http://cmake.3232098.n2.nabble.com/CMake-question-of-the-time-when-the-command-will-happen-in-add-custom-command-tp7593314p7593320.html
Sent from the CMake mailing list archive at Nabble.com.
-- 

Powered by www.kitware.com

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

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

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

Re: [CMake] CMake:question of the time when the command will happen in add_custom_command(...)

2016-04-22 Thread Petr Kmoch
No, it is indeed compiled and linked just fine. What I meant is:

Without any custom commands, the build process conceptually looks like this:

buildMain() {
  compile_object_files();
  link_main_binary();

  message("Built target main");
}

With a post-build custom command:

buildMain() {
  compile_object_files();
  link_main_binary();
  post_build_command();

  message("Built target main");
}

The custom command becomes a part of the entire process of "Building
target," that's why the "Built target" message appears after the command
runs.

BTW, please keep the mailing list in copy when replying.

Petr

On 22 April 2016 at 10:02, Chaos Zhang  wrote:

> So what you mean is the target have not been complied and linked after i 
> introduce
> custom commands into this target right? Do i understand right?
>
> Thanks a lot for your generous help. :-)
>
> 2016-04-22 16:38 GMT+08:00 Petr Kmoch :
>
>> Hi,
>>
>> the reason is that the post-build command is actually a part of building
>> "main the target." Once you introduce custom commands into a target,
>> building it includes them all, and not just compiling the object files and
>> linking the binary. You will notice that the "Linking C exectuable main"
>> line came before the post-build message, so it did happen in the correct
>> order.
>>
>> Petr
>>
>> On 22 April 2016 at 06:25, Chaos Zhang  wrote:
>>
>>> Hi all,
>>>
>>> I have some trouble when i use PRE_BUILD | PRE_LINK | POST_BUILD in
>>> command
>>> "add_custom_command(...)". When i use POST_BUILD, i found the command
>>> will
>>> execute before target had been built, like this:
>>>
>>> 1 [root@VM_33_35_centos build]# make
>>> 2 Scanning dependencies of target main
>>> 3 [100%] Building C object CMakeFiles/main.dir/main.c.o
>>> 4 Linking C executable main
>>> 5 This is pre build
>>> 6 This is post build
>>> 7 [100%] Built target main
>>>
>>> In my CMakeLists.txt, the content is:
>>>  1 cmake_minimum_required(VERSION 2.8)
>>>  2 add_executable(main main.c)
>>>  3 add_custom_command(TARGET main
>>>  4 PRE_BUILD
>>>  5 COMMAND echo "This is pre build "
>>>  6 )
>>>  7 add_custom_command(TARGET main
>>>  8 POST_BUILD
>>>  9 COMMAND echo "This is post build"
>>>  10 )
>>>
>>> Why the command echo "This is post build" in 8 line(CMakeLists.txt) did
>>> not
>>> execute after [100%] Built target main in 7 line(Linux command)?
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://cmake.3232098.n2.nabble.com/CMake-question-of-the-time-when-the-command-will-happen-in-add-custom-command-tp7593314.html
>>> Sent from the CMake mailing list archive at Nabble.com.
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
>>>
>>
>>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Using Clang + Ninja on Windows?

2016-04-22 Thread Mueller-Roemer, Johannes Sebastian
It is true that there is no official bundled installer with both, but the 
official installer works just fine with mingw as long as you pass in the 
correct target to clang(++)

For example
clang++ --target=x86_64-w64-mingw32 test.cpp

However, it assumes that mingw64 is installed under C:/mingw64 (the default 
location, it’ll work with a junction point though).


From: Cristian Adam [mailto:cristian.a...@gmail.com]
Sent: Friday, April 22, 2016 09:15
To: Mueller-Roemer, Johannes Sebastian 

Cc: cmake@cmake.org
Subject: Re: [CMake] Using Clang + Ninja on Windows?

On Fri, Apr 22, 2016 at 8:59 AM, Mueller-Roemer, Johannes Sebastian 
>
 wrote:
You are mistaken, Clang absolutely also works with MinGW. Or it did at least up 
to 3.7 (didn’t get around to trying 3.8 yet)


Clang works fine with libstdc++ on Linux and Cygwin, there should be no reason 
why it shouldn't work with MinGW.

What I should have wrote was that Clang on Windows officially supports only a 
Visual C++ setup / Visual Studio integration.

I don't think I have seen a package containing clang and libstdc++ from MinGW.

Cheers,
Cristian.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake:question of the time when the command will happen in add_custom_command(...)

2016-04-22 Thread Petr Kmoch
Hi,

the reason is that the post-build command is actually a part of building
"main the target." Once you introduce custom commands into a target,
building it includes them all, and not just compiling the object files and
linking the binary. You will notice that the "Linking C exectuable main"
line came before the post-build message, so it did happen in the correct
order.

Petr

On 22 April 2016 at 06:25, Chaos Zhang  wrote:

> Hi all,
>
> I have some trouble when i use PRE_BUILD | PRE_LINK | POST_BUILD in command
> "add_custom_command(...)". When i use POST_BUILD, i found the command will
> execute before target had been built, like this:
>
> 1 [root@VM_33_35_centos build]# make
> 2 Scanning dependencies of target main
> 3 [100%] Building C object CMakeFiles/main.dir/main.c.o
> 4 Linking C executable main
> 5 This is pre build
> 6 This is post build
> 7 [100%] Built target main
>
> In my CMakeLists.txt, the content is:
>  1 cmake_minimum_required(VERSION 2.8)
>  2 add_executable(main main.c)
>  3 add_custom_command(TARGET main
>  4 PRE_BUILD
>  5 COMMAND echo "This is pre build "
>  6 )
>  7 add_custom_command(TARGET main
>  8 POST_BUILD
>  9 COMMAND echo "This is post build"
>  10 )
>
> Why the command echo "This is post build" in 8 line(CMakeLists.txt) did not
> execute after [100%] Built target main in 7 line(Linux command)?
>
>
>
>
> --
> View this message in context:
> http://cmake.3232098.n2.nabble.com/CMake-question-of-the-time-when-the-command-will-happen-in-add-custom-command-tp7593314.html
> Sent from the CMake mailing list archive at Nabble.com.
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0016075]: Play jeopardy theme during compilation

2016-04-22 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16075 
== 
Reported By:Richard Wiedenhöft
Assigned To:
== 
Project:CMake
Issue ID:   16075
Category:   CMake
Reproducibility:N/A
Severity:   feature
Priority:   normal
Status: new
== 
Date Submitted: 2016-04-22 03:53 EDT
Last Modified:  2016-04-22 03:53 EDT
== 
Summary:Play jeopardy theme during compilation
Description: 
I'd like to request the addition of a command line flag that enables playback of
the Jeopardy theme while a compilation is running.

This should be trivially possible using mplayer (on Linux at least).

Reasons:
- It would be awesome
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-22 03:53 Richard WiedenhöftNew Issue   

==

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Using Clang + Ninja on Windows?

2016-04-22 Thread Cristian Adam
On Fri, Apr 22, 2016 at 8:59 AM, Mueller-Roemer, Johannes Sebastian <
johannes.sebastian.mueller-roe...@igd.fraunhofer.de> wrote:

> You are mistaken, Clang absolutely also works with MinGW. Or it did at
> least up to 3.7 (didn’t get around to trying 3.8 yet)
>
>
>

Clang works fine with libstdc++ on Linux and Cygwin, there should be no
reason why it shouldn't work with MinGW.

What I should have wrote was that Clang on Windows officially supports only
a Visual C++ setup / Visual Studio integration.

I don't think I have seen a package containing clang and libstdc++ from
MinGW.

Cheers,
Cristian.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Using Clang + Ninja on Windows?

2016-04-22 Thread Mueller-Roemer, Johannes Sebastian
You are mistaken, Clang absolutely also works with MinGW. Or it did at least up 
to 3.7 (didn’t get around to trying 3.8 yet)

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Cristian Adam
Sent: Thursday, April 21, 2016 23:30
To: Johan Holmberg 
Cc: cmake@cmake.org
Subject: Re: [CMake] Using Clang + Ninja on Windows?


On Wed, Apr 20, 2016 at 4:01 PM, Johan Holmberg 
> wrote:
Hi!
How should I setup CMake to build a C/C++ application on Windows using 
clang/clang++ as compilers and Ninja as build tool?
I tried specifying "-GNinja" to cmake, and setting CC/CXX to clang/clang++. But 
this didn't work. I get errors like:

  clang.exe: error: no such file or directory: '/nologo'
indicating that CMake thinks it should pass Visual C++ style options to clang.
I'm thinking about fooling CMake that clang/clang++ are cross compilers (I know 
how to get cross compiling working in other cases). But since clang/clang++ are 
the native tools for Windows, I was hoping to be able to use Clang + Ninja on 
Windows almost like I use on Linux.
If I run Clang from the command line, I can build my application, so my 
Clang-installation works.

I'm using CMake 3.5.1 and Clang 3.8.0.
/Johan Holmberg

Hi,

On Windows Clang works only with Visual C++, since they don't provide libc++. 
MinGW is not supported.
Clang provides a Visual C++'s cl.exe replacement.

You need to have the official 
windows Clang and Visual C++ 
Express or Community installed.

Then it's just a matter of:
1.   Opening a Visual C++ 2013 64 bit command prompt window
2.   Putting clang's cl.exe in the path and setting clang's INCLUDE path 
first

set PATH=c:\Program Files\LLVM\msbuild-bin\;%PATH%
set INCLUDE=c:\Program Files\LLVM\lib\clang\3.8.0\include\;%INCLUDE%
3.   cmake -G "Ninja"
4.   Ninja
CMake / Ninja will think that they compile with Visual C++, but instead will 
use clang.

Note that you have to match Visual C++ and Clang's build, 32 or 64 bit. You 
can't mix them,
or you'll have weird 
errors.

Cheers,
Cristian.

P.S. This is actually a re-post, this time adding the mailing list.
-- 

Powered by www.kitware.com

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

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

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