date:20160412

Re: [cmake-developers] CMake API for warnings

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


On 13-Apr-16 01:00, Brad King wrote:

Hi Ruslo,

Sorry for taking so long to respond here.  I've been hoping to find time
to think through the design deeply but I don't know when that may happen.
Here is some more feedback.  I invite others to jump in here.  Without
more interest I'm hesitant to proceed.

On 04/05/2016 02:03 PM, Ruslan Baratov wrote:

Report an error in case of any type of conflicts.

Yes.


new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may control this.

I'd prefer to avoid extra knobs if possible.

Okay, what about CMake warning for developer? (cmake -Wdev/cmake -Wno-dev)




You mean this:

  compatibility-c++98=off
  inline=off
  special-members=off
  catch-semantic-changed=off
  covered-switch-default=off
  inherits-via-dominance=off
  name-length-exceeded=off
  padded=off
  this-used-in-init=off
  EVERYTHING=on
  EVERYTHING=error

versus this one:

  DISABLE
compatibility-c++98
inline
special-members
catch-semantic-changed
covered-switch-default
inherits-via-dominance
name-length-exceeded
padded
this-used-in-init
  ENABLE
EVERYTHING
  TREAT_AS_ERROR
EVERYTHING

Consider examples where we don't have the full list ahead of time and
are instead appending.

-


   Or, what if we want to check the current property
value to see if some setting is already present?

What do you mean?


   Compilers use flags like

   -Wxyz -Wno-abc -Whjk=error

and not

   -WDISABLE $w1 $w2 -WENABLE $w3 $w4
I don't think the reason of approach used in compilers is about been 
convenient for user to analyze command line flags. CMake can do much 
better job here.
All I'm trying to say about ENABLE/DISABLE lists is that if user will 
have N warnings to enable and M warnings to disable he will not write N 
times *=on and M times *=off and probably will just create helper functions:


function(enable_warnings_list ...)
  foreach(warning ...)
list(APPEND result ${warning}=on)
  endforeach()
endif()

So instead of writing extra different modules by a lot of developers why 
not support this from the box?




so IMO the individual values are easier to reason about.  Also one could
imagine having the value come from a generator expression, e.g.

foo=$
As far as I understand we should allow on/off/error, so effectively it 
will be:


foo=$<$:off>$<$:error>

so how about this:

   compile_warnings(DISABLE foo CONFIGURATION Debug)
   compile_warnings(ERROR foo CONFIGURATION NOT Debug)

?




I'd like to find another name that captures the idea of enabling most warnings.

Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET?

I don't think "everything" or "all" has a meaningful implementation
available on all compilers.  I was actually saying the opposite.
We should not try to provide such an abstraction and instead have
one called "most" or "high" or something like that.
I'm pretty sure all compilers have flag to enable all kind of available 
warnings (it may not call "All", e.g. -Weverything for Clang). Even if 
there is such compiler we can use maximum level + adding extra warnings 
explicitly. There must be abstracted group that allow to enable 
everything. Also I think that LEVEL/MOST/ALL groups doesn't make a 
lot of practical sense since every compiler have different kind of 
warnings enabled by such groups, so it's not cross-platformic friendly.


Ruslo
--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] [CMake 0016060]: Chrome warns cmake installer is harmful program

2016-04-12 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16060 
== 
Reported By:raysatiro
Assigned To:
== 
Project:CMake
Issue ID:   16060
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2016-04-12 17:52 EDT
Last Modified:  2016-04-12 17:52 EDT
== 
Summary:Chrome warns cmake installer is harmful program
Description: 
Using Chrome Version 49.0.2623.112 m I'm trying to download the cmake installer:

"The site ahead contains harmful programs

Attackers on cmake.org might attempt to trick you into installing programs that
harm your browsing experience (for example, by changing your homepage or showing
extra ads on sites you visit)."



Steps to Reproduce: 
https://cmake.org/download/ and click on cmake-3.5.1-win32-x86.msi

Additional Information: 
https://www.google.com/transparencyreport/safebrowsing/diagnostic/index.html?hl=en-US#url=https://cmake.org/files/v3.5/cmake-3.5.1-win32-x86.msi
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-12 17:52 raysatiro  New Issue
2016-04-12 17:52 raysatiro  File Added: cmake chrome says harmful
programs.PNG
==

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Automoc same source - More thoughts

2016-04-12 Thread Brad King

On 04/12/2016 03:12 PM, Sebastian Holtermann wrote:
> Here it is. Please review/commit.
> 
> To test it insert #include "moc_item.cpp" in any or many
> of the item.cpp files of the attached test project.

Thanks for working on this!

As requested in the issue tracker entry you linked,
in this comment:

  https://cmake.org/Bug/view.php?id=12873#c40513

please extend the CMake test suite with a case covering
this.  We need to test both the conflicting source name
use case and the #include "moc_..." use case.  Please
revise the patch to include such tests.

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] Automoc same source - More thoughts

2016-04-12 Thread Sebastian Holtermann


Am 12.04.2016 um 17:40 schrieb Sebastian Holtermann:

Am 12.04.2016 um 13:43 schrieb Sebastian Holtermann:

Sorry for the noise.


I've stumbled over bug
https://cmake.org/Bug/view.php?id=12873
a few times now since I like to use same named data/view classes.

I've prepared a fix that generates all moc_xxx.cpp files
in the foo_automoc.dir subdirectory.




I had some more thoughts about this.

CMAKE_CURRENT_BINARY_DIR /
   foo_automoc.cpp
   foo_automoc.dir/data/moc_item.cpp
   foo_automoc.dir/view/moc_item.cpp
   foo_automoc.dir/moc_item.cpp

With directory based moc file generation it is complicated to allow
"#include " (I've never included mocs btw.).
Putting every moc directory into the target INCLUDE_DIRECTORIES
won't help because then there would be multiple moc_item.cpp
files that match "include ".
If per source INCLUDE_DIRECTORIES were possible it might work though.

My proposal is this:

- Moc files that are "#include<>"d get generated in
CMAKE_CURRENT_BINARY_DIR/moc_xxx.cpp as before but with
name collision test.

- Moc files not included but detected from
headers get generated in
CMAKE_CURRENT_BINARY_DIR/foo_automoc.dir/
with subdirectory support.
Since they're not included it doesn't matter where they are as long as
they don't overwrite each other.


I'll prepare another patch for this...



Here it is. Please review/commit.

To test it insert #include "moc_item.cpp" in any or many
of the item.cpp files of the attached test project.


Kind regards,
Sebastian Holtermann


>From cbc41b51685a4a35ceaa0763ba3f14e1ae425ad4 Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann 
Date: Tue, 12 Apr 2016 20:49:50 +0200
Subject: [PATCH] Automoc generates non included mocs in dedicated directory
 with source directory tree reflection

---
 Source/cmQtAutoGenerators.cxx | 107 +++---
 Source/cmQtAutoGenerators.h   |   4 ++
 2 files changed, 104 insertions(+), 7 deletions(-)

diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index ebe08b0..1faab2d 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -93,8 +93,19 @@ static std::string extractSubDir(const std::string& absPath,
   std::string subDir;
   if (currentMoc.find_first_of('/') != std::string::npos)
 {
-subDir = absPath
-  + cmsys::SystemTools::GetFilenamePath(currentMoc) + '/';
+std::string fileNamePath = cmsys::SystemTools::GetFilenamePath(currentMoc);
+if ( fileNamePath.find ( ".." ) == std::string::npos )
+  {
+subDir = absPath + fileNamePath + '/';
+  }
+else
+  {
+  // We can't handle parent directories
+  std::cerr << "AUTOGEN: error: moc include \"" << currentMoc
+<< "\" contains parent directory reference \"..\""
+<< std::endl;
+  ::exit(EXIT_FAILURE);
+  }
 }
   return subDir;
 }
@@ -414,6 +425,9 @@ void cmQtAutoGenerators::Init()
   this->OutMocCppFilename += this->TargetName;
   this->OutMocCppFilename += ".cpp";
 
+  this->OutMocDirname += this->TargetName;
+  this->OutMocDirname += ".dir";
+
   std::vector cdefList;
   cmSystemTools::ExpandListArgument(this->MocCompileDefinitionsStr, cdefList);
   for(std::vector::const_iterator it = cdefList.begin();
@@ -589,6 +603,26 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
   std::map notIncludedMocs;
   this->ParseHeaders(headerFiles, includedMocs, notIncludedMocs, includedUis);
 
+  // Check: Look for name collisions
+{
+typedef std::map::const_iterator Iter;
+for ( Iter ita = includedMocs.begin(); ita != includedMocs.end(); ++ita )
+  {
+  Iter itb = ita;
+  ++itb;
+  for ( ; itb != includedMocs.end(); ++itb )
+{
+if ( ita->second == itb->second )
+  {
+  std::cerr << "AUTOGEN: error: moc name collision" << std::endl
+<< ita->first << " -> " << ita->second << std::endl
+<< itb->first << " -> " << itb->second << std::endl;
+  ::exit(EXIT_FAILURE);
+  }
+}
+  }
+}
+
   // run moc on all the moc's that are #included in source files
   for(std::map::const_iterator
  it = includedMocs.begin();
@@ -1104,15 +1138,14 @@ void cmQtAutoGenerators::ParseHeaders(const std::set& absHeaders,
 std::cout << "AUTOGEN: Checking " << headerName << std::endl;
 }
 
-  const std::string basename = cmsys::SystemTools::
-   GetFilenameWithoutLastExtension(headerName);
-
-  const std::string currentMoc = "moc_" + basename + ".cpp";
   std::string macroName;
   if (requiresMocing(contents, macroName))
 {
 //std::cout << "header contains Q_OBJECT macro";
-notIncludedMocs[headerName] = currentMoc;
+const std::string basename = cmsys::SystemTools::

Re: [cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

2016-04-12 Thread Brad King

On 04/12/2016 02:54 PM, Robert Dailey wrote:
> set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} )
> 
> if( BUILD_TESTING )
> set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" )
> endif()
> 
> However this fails stating those targets do not exist.

They don't exist because they are not created until generate-time.

FYI recent changes in 'master' move ALL_BUILD into the predefined
targets folder.

> Does CMake only allow you to set properties on targets created
> directly by the scripts themselves (i.e. no built-in targets can be
> affected)?

Correct.  See above.  This is not trivial to change because the
ALL_BUILD, INSTALL, etc. targets are not normal targets.
Internally they have type GLOBAL_TARGET.  There can be *multiple*
such targets of the same name created by the generators.  Each
directory whose CMakeLists.txt file calls project(SomeName) gets
a SomeName.sln in VS, for example.  Each such .sln has a different
ALL_BUILD target with its own dependencies.  The generators can
get away with this because nothing ever looks up these targets
by name.  Therefore trying to present such targets to CMake
project code is not well-defined.

-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-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

2016-04-12 Thread Robert Dailey

I have the following CMake code:

get_property( predefined_folder GLOBAL PROPERTY PREDEFINED_TARGETS_FOLDER )

set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} )

if( BUILD_TESTING )
set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" )
endif()

However this fails stating those targets do not exist. Is there a way
I can make this work? I'd like to organize these CMake targets in my
own way in the Visual Studio solution. There have been topics
regarding this on the mailing list in the past, but they have gone
unanswered.

Specifically, why are these targets treated as if they do not exist?
Does CMake only allow you to set properties on targets created
directly by the scripts themselves (i.e. no built-in targets can be
affected)?

I'm happy to contribute a patch to this if needed.

Thanks in advance.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake API for warnings

2016-04-12 Thread Brad King

Hi Ruslo,

Sorry for taking so long to respond here.  I've been hoping to find time
to think through the design deeply but I don't know when that may happen.
Here is some more feedback.  I invite others to jump in here.  Without
more interest I'm hesitant to proceed.

On 04/05/2016 02:03 PM, Ruslan Baratov wrote:
> Report an error in case of any type of conflicts.

Yes.

> new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may control this.

I'd prefer to avoid extra knobs if possible.

> You mean this:
> 
>  compatibility-c++98=off
>  inline=off
>  special-members=off
>  catch-semantic-changed=off
>  covered-switch-default=off
>  inherits-via-dominance=off
>  name-length-exceeded=off
>  padded=off
>  this-used-in-init=off
>  EVERYTHING=on
>  EVERYTHING=error
> 
> versus this one:
> 
>  DISABLE
>compatibility-c++98
>inline
>special-members
>catch-semantic-changed
>covered-switch-default
>inherits-via-dominance
>name-length-exceeded
>padded
>this-used-in-init
>  ENABLE
>EVERYTHING
>  TREAT_AS_ERROR
>EVERYTHING

Consider examples where we don't have the full list ahead of time and
are instead appending.  Or, what if we want to check the current property
value to see if some setting is already present?  Compilers use flags like

  -Wxyz -Wno-abc -Whjk=error

and not

  -WDISABLE $w1 $w2 -WENABLE $w3 $w4

so IMO the individual values are easier to reason about.  Also one could
imagine having the value come from a generator expression, e.g.

   foo=$

>> I'd like to find another name that captures the idea of enabling most 
>> warnings.
> 
> Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET?

I don't think "everything" or "all" has a meaningful implementation
available on all compilers.  I was actually saying the opposite.
We should not try to provide such an abstraction and instead have
one called "most" or "high" or something like that.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0016059]: It is not possible to specify a linker different from the compiler to link a shared library

2016-04-12 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16059 
== 
Reported By:Antonio
Assigned To:
== 
Project:CMake
Issue ID:   16059
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-04-12 12:00 EDT
Last Modified:  2016-04-12 12:00 EDT
== 
Summary:It is not possible to specify a linker different
from the compiler to link a shared library
Description: 
In some situations, it might be convenient to specify a different linker than
the compiler. For example, for llvm combined with mingw, compiling with clang
and linking with gcc would work. The workaround proposed here
https://cmake.org/pipermail/cmake/2014-August/058268.html does not seem to work.

Steps to Reproduce: 
Requires 2 compilers to be there. In the attached project,
Configuring with 
D:\dummyProj\build> cmake ..\src -G "Eclipse CDT4 - Ninja"
-DCMAKE_TOOLCHAIN_FILE=..\src\Toolchain-LLVM.cmake 
-DCMAKE_LINKER=C:/Programs/mingw32_493_posix_dwarf/bin/g++.exe
-DCMAKE_CXX_LINK_EXECUTABLE="  
  -o  " 
-DCMAKE_CXX_CREATE_SHARED_LIBRARY="
  
  -o 
 "

Building will anyway lead to the following commands to be generated:
[1/2] C:\Programs\LLVM\bin\clang++.exe   -Ddummy_EXPORTS   -MMD -MT
CMakeFiles/dummy.dir/dummy.cpp.obj -MF CMakeFiles/dummy.dir/dummy.cpp.obj.d -o
CMakeFiles/dummy.dir/dummy.cpp.obj -c D:/dummyProj/src/dummy.cpp
[2/2] cmd.exe /C "cd . && C:\Programs\LLVM\bin\clang++.exe  -shared -o
libdummy.dll -Wl,--out-implib,libdummy.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
CMakeFiles/dummy.dir/dummy.cpp.obj  -lkernel32 -luser32 -lgdi32 -lwinspool
-lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
FAILED: cmd.exe /C "cd . && C:\Programs\LLVM\bin\clang++.exe  -shared -o
libdummy.dll -Wl,--out-implib,libdummy.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
CMakeFiles/dummy.dir/dummy.cpp.obj  -lkernel32 -luser32 -lgdi32 -lwinspool
-lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
C:\Programs\mingw32_493_posix_dwarf\i686-w64-mingw32\lib/libmingw32.a(lib32_libmingw32_a-pseudo-reloc.o):pseudo-reloc.c:(.text+0x1d6):
undefined reference to `__chkstk_ms'

clang++.exe: error: linker command failed with exit code 1 (use -v to see
invocation)

ninja: build stopped: subcommand failed.

The first command is correct, the second doesn't use g++ to link as desired.
Linking succeeds if g++ is replaced in the command line.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-12 12:00 AntonioNew Issue
2016-04-12 12:00 AntonioFile Added: dummyProj.zip
==

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Automoc same source - More thoughts

2016-04-12 Thread Sebastian Holtermann


Am 12.04.2016 um 13:43 schrieb Sebastian Holtermann:

Sorry for the noise.


I've stumbled over bug
https://cmake.org/Bug/view.php?id=12873
a few times now since I like to use same named data/view classes.

I've prepared a fix that generates all moc_xxx.cpp files
in the foo_automoc.dir subdirectory.




I had some more thoughts about this.

CMAKE_CURRENT_BINARY_DIR /
  foo_automoc.cpp
  foo_automoc.dir/data/moc_item.cpp
  foo_automoc.dir/view/moc_item.cpp
  foo_automoc.dir/moc_item.cpp

With directory based moc file generation it is complicated to allow 
"#include " (I've never included mocs btw.).

Putting every moc directory into the target INCLUDE_DIRECTORIES
won't help because then there would be multiple moc_item.cpp
files that match "include ".
If per source INCLUDE_DIRECTORIES were possible it might work though.

My proposal is this:

- Moc files that are "#include<>"d get generated in
CMAKE_CURRENT_BINARY_DIR/moc_xxx.cpp as before but with
name collision test.

- Moc files not included but detected from
headers get generated in
CMAKE_CURRENT_BINARY_DIR/foo_automoc.dir/
with subdirectory support.
Since they're not included it doesn't matter where they are as long as
they don't overwrite each other.


I'll prepare another patch for this...

Kind regards,
Sebastian



--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Automoc same source name fix (proposal)

2016-04-12 Thread Sebastian Holtermann


Am 12.04.2016 um 11:57 schrieb Sebastian Holtermann:

Oops, moc_item.cpp it is.


For the attached test case you end up with


foo_automoc.cpp -- As before but includes sources below
foo_automoc.dir/data/moc_item.cpp
foo_automoc.dir/view/moc_item.cpp
foo_automoc.dir/moc_item.cpp


--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Automoc same source name fix (proposal)

2016-04-12 Thread Sebastian Holtermann


Hi,

I've stumbled over bug
https://cmake.org/Bug/view.php?id=12873
a few times now since I like to use same named data/view classes.

I've prepared a fix that generates all moc_xxx.cpp files
in the foo_automoc.dir subdirectory.
For the attached test case you end up with

foo_automoc.cpp -- As before but includes sources below
foo_automoc.dir/data/moc_item.cpp
foo_automoc.dir/view/moc_item.cpp
foo_automoc.dir/item.cpp

This solves the same output moc problem.

What remains though is that including "moc_foo.cpp"
does not work because of missing INCLUDE_DIRECTORIES.

Kind regards,
Sebastian Holtermann

>From cf51dcf0af4744fbb40e3bb5ad253d2514325148 Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann 
Date: Tue, 12 Apr 2016 10:47:49 +0200
Subject: [PATCH] Automoc: Create moc files below foo_automoc.dir with respect
 to the source header project relative path

---
 Source/cmQtAutoGenerators.cxx | 90 ---
 Source/cmQtAutoGenerators.h   |  3 ++
 2 files changed, 80 insertions(+), 13 deletions(-)

diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index ebe08b0..69b1e3d 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -414,6 +414,9 @@ void cmQtAutoGenerators::Init()
   this->OutMocCppFilename += this->TargetName;
   this->OutMocCppFilename += ".cpp";
 
+  this->OutMocDirname += this->TargetName;
+  this->OutMocDirname += ".dir";
+
   std::vector cdefList;
   cmSystemTools::ExpandListArgument(this->MocCompileDefinitionsStr, cdefList);
   for(std::vector::const_iterator it = cdefList.begin();
@@ -637,7 +640,7 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
 {
 automocCppChanged = true;
 }
-  outStream << "#include \"" << it->second << "\"\n";
+  outStream << "#include \"" << MocPathBuildRel ( it->second ) << "\"\n";
   }
 }
 
@@ -749,7 +752,7 @@ void cmQtAutoGenerators::ParseCppFile(const std::string& absFilename,
 
 if (!headerToMoc.empty())
   {
-  includedMocs[headerToMoc] = currentMoc;
+  includedMocs[headerToMoc] = MocPathIncluderRel ( absFilename, currentMoc );
   if (basename == scannedFileBasename)
 {
 mocUnderscoreIncluded = true;
@@ -826,7 +829,7 @@ void cmQtAutoGenerators::ParseCppFile(const std::string& absFilename,
   dotMocIncluded = true;
   ownDotMocFile = currentMoc;
   }
-includedMocs[fileToMoc] = currentMoc;
+includedMocs[fileToMoc] = MocPathIncluderRel ( absFilename, currentMoc );
 }
   matchOffset += mocIncludeRegExp.end();
   } while(mocIncludeRegExp.find(contentsString.c_str() + matchOffset));
@@ -851,7 +854,7 @@ void cmQtAutoGenerators::ParseCppFile(const std::string& absFilename,
 << scannedFileBasename << ".moc\" for compatibility with "
"strict mode (see CMAKE_AUTOMOC_RELAXED_MODE).\n"
 << std::endl;
-  includedMocs[absFilename] = ownMocUnderscoreFile;
+  includedMocs[absFilename] = MocPathIncluderRel ( absFilename, ownMocUnderscoreFile );
   includedMocs.erase(ownMocHeaderFile);
   }
 else
@@ -930,7 +933,7 @@ void cmQtAutoGenerators::StrictParseCppFile(const std::string& absFilename,
 
 if (!headerToMoc.empty())
   {
-  includedMocs[headerToMoc] = currentMoc;
+  includedMocs[headerToMoc] = MocPathIncluderRel ( absFilename, currentMoc );
   }
 else
   {
@@ -964,7 +967,7 @@ void cmQtAutoGenerators::StrictParseCppFile(const std::string& absFilename,
   ::exit(EXIT_FAILURE);
   }
 dotMocIncluded = true;
-includedMocs[absFilename] = currentMoc;
+includedMocs[absFilename] = MocPathIncluderRel ( absFilename, currentMoc );
 }
   matchOffset += mocIncludeRegExp.end();
   } while(mocIncludeRegExp.find(contentsString.c_str() + matchOffset));
@@ -1104,15 +1107,14 @@ void cmQtAutoGenerators::ParseHeaders(const std::set& absHeaders,
 std::cout << "AUTOGEN: Checking " << headerName << std::endl;
 }
 
-  const std::string basename = cmsys::SystemTools::
-   GetFilenameWithoutLastExtension(headerName);
-
-  const std::string currentMoc = "moc_" + basename + ".cpp";
   std::string macroName;
   if (requiresMocing(contents, macroName))
 {
 //std::cout << "header contains Q_OBJECT macro";
-notIncludedMocs[headerName] = currentMoc;
+const std::string basename = cmsys::SystemTools::
+ GetFilenameWithoutLastExtension(headerName);
+const std::string currentMoc = "moc_" + basename + ".cpp";
+notIncludedMocs[headerName] = MocPathIncluderRel ( headerName, currentMoc );
 }
   }
 this->ParseForUic(headerName, contents, includedUis);
@@ -1122,7 +1124,11 @@ void

Re: [cmake-developers] CMake API for warnings

[cmake-developers] [CMake 0016060]: Chrome warns cmake installer is harmful program

Re: [cmake-developers] Automoc same source - More thoughts

Re: [cmake-developers] Automoc same source - More thoughts

Re: [cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

[cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS

Re: [cmake-developers] CMake API for warnings

[cmake-developers] [CMake 0016059]: It is not possible to specify a linker different from the compiler to link a shared library

Re: [cmake-developers] Automoc same source - More thoughts

Re: [cmake-developers] Automoc same source name fix (proposal)

[cmake-developers] Automoc same source name fix (proposal)

11 matches

Site Navigation

Mail list logo

Footer information