Re: [cmake-developers] Moc-test errors

[Sebastian Holtermann]

BTW, with todays compilation (master branch) also some qt4-moc-tests are 
failing.
This starts to be itching ...


# ctest -R Autogen.Moc
...
The following tests FAILED:
 577 - Qt5Autogen.MocIncludeRelaxed (Failed)
 578 - Qt5Autogen.MocIncludeStrict (Failed)
 579 - Qt5Autogen.MocSkipSource (Failed)
 615 - Qt4Autogen.MocIncludeRelaxed (Failed)
 616 - Qt4Autogen.MocIncludeStrict (Failed)
 617 - Qt4Autogen.MocSkipSource (Failed)
Errors while running CTest

Kornel


I was able to reproduce the issue.  It appears when the CMake sources 
are in a path that contains symbolic links.

Please see issue https://gitlab.kitware.com/cmake/cmake/issues/19346

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

Re: [cmake-developers] Moc-test errors

[Sebastian Holtermann]

The following tests FAILED:
577 - Qt5Autogen.MocIncludeRelaxed (Failed)
578 - Qt5Autogen.MocIncludeStrict (Failed)
579 - Qt5Autogen.MocSkipSource (Failed)
Errors while running CTest



Okay, it looks like SKIP_AUTOMOC doesn't work properly.
Can you please post the output of

- `ctest -R Qt5Autogen.MocSkip -VV`
- `cat
Tests/Qt5Autogen/MocSkipSource/CMakeFiles/skipMocA_autogen.dir/AutogenInfo.cmake`
- `cat
Tests/Qt5Autogen/MocSkipSource/CMakeFiles/skipMocB_autogen.dir/AutogenInfo.cmake`


OK, attached.



BTW, with todays compilation (master branch) also some qt4-moc-tests are 
failing.
This starts to be itching ...


# ctest -R Autogen.Moc
...
The following tests FAILED:
 577 - Qt5Autogen.MocIncludeRelaxed (Failed)
 578 - Qt5Autogen.MocIncludeStrict (Failed)
 579 - Qt5Autogen.MocSkipSource (Failed)
 615 - Qt4Autogen.MocIncludeRelaxed (Failed)
 616 - Qt4Autogen.MocIncludeStrict (Failed)
 617 - Qt4Autogen.MocSkipSource (Failed)
Errors while running CTest


Thanks for the files.

For some reason the file processing flags are wrong.
E.g. in AutogenInfo-1.cmake
  set(AM_HEADERS_FLAGS "mU;MU;MU")
should be
  set(AM_HEADERS_FLAGS "mU;mU;mu")
A lower case letter means no moc/uic processing.

It seems to be something wrong with SKIP_AUTOMOC/GEN flags of headers 
that were found from their source files.


Are there symbolic directory links involved in either the CMake source 
directory or the CMake build directory?


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

Re: [cmake-developers] Moc-test errors

[Sebastian Holtermann]

Sure, rebuild_cache was the first I tried. The test-errors remain even in the 
master tree of today.
Performing now on a clean build ...
#ctest -R Qt5Autogen.Moc
Test project /BUILD/BUILDMint18/BuildCmakeGit
Guessing configuration NoConfig
 Start 553: Qt5Autogen.MocOnly
1/8 Test #553: Qt5Autogen.MocOnly ...   Passed2.04 sec
 Start 554: Qt5Autogen.MocOptions
2/8 Test #554: Qt5Autogen.MocOptions    Passed1.40 sec
 Start 576: Qt5Autogen.MocCMP0071
3/8 Test #576: Qt5Autogen.MocCMP0071    Passed2.48 sec
 Start 577: Qt5Autogen.MocIncludeRelaxed
4/8 Test #577: Qt5Autogen.MocIncludeRelaxed .***Failed4.37 sec
 Start 578: Qt5Autogen.MocIncludeStrict
5/8 Test #578: Qt5Autogen.MocIncludeStrict ..***Failed4.24 sec
 Start 579: Qt5Autogen.MocSkipSource
6/8 Test #579: Qt5Autogen.MocSkipSource .***Failed2.99 sec
 Start 580: Qt5Autogen.MocMacroName
7/8 Test #580: Qt5Autogen.MocMacroName ..   Passed1.95 sec
 Start 581: Qt5Autogen.MocOsMacros
8/8 Test #581: Qt5Autogen.MocOsMacros ...   Passed0.56 sec

63% tests passed, 3 tests failed out of 8

Total Test time (real) =  20.09 sec

The following tests FAILED:
577 - Qt5Autogen.MocIncludeRelaxed (Failed)
578 - Qt5Autogen.MocIncludeStrict (Failed)
579 - Qt5Autogen.MocSkipSource (Failed)
Errors while running CTest



Okay, it looks like SKIP_AUTOMOC doesn't work properly.
Can you please post the output of

- `ctest -R Qt5Autogen.MocSkip -VV`
- `cat 
Tests/Qt5Autogen/MocSkipSource/CMakeFiles/skipMocA_autogen.dir/AutogenInfo.cmake`
- `cat 
Tests/Qt5Autogen/MocSkipSource/CMakeFiles/skipMocB_autogen.dir/AutogenInfo.cmake`

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution

[Sebastian Holtermann]

Am 16.05.19 um 20:43 schrieb Venedict Tchistopolskii:

Hey again, just checking in.

Has this been solved with a better solution/etc.? .-.

VT


AFAIK setting source file properties on files that get tagged
GENERATED later has been fixed by this commit:

https://gitlab.kitware.com/cmake/cmake/commit/254b7260f49caaca78b16761d70d6239626d2129

So it should work in CMake 3.14 and higher.

If this is the best solution for the issue is a different question.
Check issue https://gitlab.kitware.com/cmake/cmake/issues/19266,
for another solution approach (not implemented, yet).

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

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

[Sebastian Holtermann]

after changing my account (@sebholt) password in gitlab.kitware.com, I
don't get any emails from it anymore.  Login and everything web based
works, but no emails.  Did something change there?


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

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

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


This looks all good.
I also updated the Let's encrypt certificate on xwmw.org.
Maybe that's what caused the issues.

Anyway I'm using an email address from a larger provider in gitlab now 
and it seems to work.


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

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

[Sebastian Holtermann]

Hi,

after changing my account (@sebholt) password in gitlab.kitware.com, I 
don't get any emails from it anymore.  Login and everything web based 
works, but no emails.  Did something change there?


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

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

[Sebastian Holtermann]

Looking through the source code I found various comments
starting with "///!"
If Doxygen is targeted, the comment should start with either "///" or
"//!".


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



Okay, then why not do a cleanup that replaces "///!" with "//!"?
I'll prepare a patch for that.

--

Powered by www.kitware.com

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

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

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

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

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

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

[Sebastian Holtermann]

Looking through the source code I found various comments
starting with "///!"

E.g.:
```
///! myFunction description
myFunction()
```

To my blame, I've use it as well.  But is this a valid meta notation?
If Doxygen is targeted, the comment should start with either "///" or
"//!".  When the comment starts with "///!", the exclamation mark ends 
up in the comment text. This looks very wrong in the few cases I've checked.


For reference
http://www.doxygen.nl/manual/docblocks.html

Any ideas?

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution

[Sebastian Holtermann]

> Any luck? I can try helping ya trace it if you need it.
> 

I traced this down to some degree.
The problem arises from the handling of file path for GENERATED vs non 
GENERATED files.
When the full path for a file is computed in cmSourceFile and the file doesn't
exist (mocs_compilation.cpp doesn't, yet), a path error flag is set.
The flag won't be raised when the file has the property GENERATED set, which
mocs_compilation.cpp hasn't at that point.

A quick solution in your CMakeLists.txt is to mark mocs_compilation.cpp
GENERATED first like this

```
set_property(SOURCE "${MOC_COMPILATION}" APPEND_STRING PROPERTY GENERATED "1")
set_property(SOURCE "${MOC_COMPILATION}" APPEND_STRING PROPERTY COMPILE_FLAGS 
" /FI\"${PrecompiledHeader}\"")
```

This works here for a small example project.

I'm too busy right now to address this in the CMake sources but I'll try to 
look at it next week.

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

Re: [cmake-developers] CMake 3.13 - Generated moc files not added to VStudio solution

[Sebastian Holtermann]

Hello Venedict,

I took a look at this again, thanks for the additional information.
In fact this isn't VS specific. I was able to reproduce the issue using
Linux/Makefiles.

> Got the fix, hopefully it can be merged in :)
> https://github.com/Personwithhat/custom_cmake/commit/d7930c36c6aa7956a806a28
> 4aa7e1e430ef6c174

This change is too intrusive and breaks a lot of other things.

> >>> set (MOC_COMPILATION
> >>> "${CMAKE_CURRENT_BINARY_DIR}/${TargetProject}_autogen/mocs_compilation.c
> >>> pp") # stdafx.h needs to be included to ensure platform definitions are
> >>> visible
> >>> set_property(SOURCE "${MOC_COMPILATION}" APPEND_STRING PROPERTY
> >>> COMPILE_FLAGS " /FI\"${PrecompiledHeader}\"")

Setting compiler flags on the mocs_compilation.cpp file is the root cause.
I'll investigate this deeper.

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

Re: [cmake-developers] Undocumented CMAKE_AUTOMOC_RELAXED_MODE changes in 3.13

[Sebastian Holtermann]

Am Samstag, 26. Januar 2019, 03:27:08 CET schrieb Venedict Tchistopolskii:
> Actually, debugged a lot more and found this!
> 
> The first CMake generation pass: Generates but no inclusion
> 
> 
> 
> *Forcing a second pass makes it include the newly generated moc'*
> It says *"AutoMoc: Generating 'X' because the MOC settings changed"*
> 
> I'm not too clear on why this is happening, any ideas on how to fix it, or
> force it to reload whatever 'moc settings' are changing?
> 
> Note: This affects both relaxed and non-relaxed mode, my fix was a dummy
> because it involved regenerating cmake (ofc)which is the actual
> solution.
> 
> VT

There already is an issue reported that seems related:
https://gitlab.kitware.com/cmake/cmake/issues/17456

I'm not a Windows/VS developer and can't help much about it, sorry.
If someone else is interested in this issue, please assist.

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

Re: [cmake-developers] Undocumented CMAKE_AUTOMOC_RELAXED_MODE changes in 3.13

[Sebastian Holtermann]

Am Freitag, 25. Januar 2019, 17:36:22 CET schrieb Venedict Tchistopolskii:
> When updating the project CMake from 3.12 to 3.13,
> *CMAKE_AUTOMOC_RELAXED_MODE* stops including certain generated moc files.
> 
> Had to switch to *CMAKE_AUTOMOC *to get them included.strange
> functionality on the part of CMake.
> 
> Can't find any documentation on these changes, and if/how they were touched
> at all.

This isn't an intentional behavior change.
Could you provide a minimal example that reproduces the problem?

Also please feel free to open an issue here:
https://gitlab.kitware.com/cmake/cmake/issues

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

Re: [cmake-developers] kwsysProcess threadsafety

[Sebastian Holtermann]

On Montag, 8. Januar 2018 06:56:57 CET Brad King wrote:
> On 01/06/2018 02:31 AM, Sebastian Holtermann wrote:
> >>> 2) Use libuv instead
> > 
> > I just saw the libuv library in the CMake sources.
> > 
> >> libuv for process management is on the list. I think it is waiting for
> >> porting to all of CMake's platforms to actually happen.
> > 
> > Does that mean it's only there for some specific scenarios and shouldn't
> > be used in general?
> 
> A goal is to eventually fully replace use of KWSys Process with libuv.
> I'd prefer not to make any major changes to KWSys Process in the meantime.
> 
> Currently libuv is used only for the server mode, but soon it will be
> used for CTest too:
> 
>   https://gitlab.kitware.com/cmake/cmake/merge_requests/1455
> 
> > Looks nice, but in AUTOMOC/UIC it's sufficient to just known which child
> > processes are running and to get a notification when one has finished.
> 
> Use of libuv's process management for that would be good.  It supports
> fully asynchronous operation and so can manage many child processes from
> one thread.

Okay.
Then I'm going to refactor cmQtAutoGeneratorMocUic
to use a libuv event loop internally.

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

Re: [cmake-developers] kwsysProcess threadsafety

[Sebastian Holtermann]

> > 2) Use libuv instead

I just saw the libuv library in the CMake sources.
 
> libuv for process management is on the list. I think it is waiting for
> porting to all of CMake's platforms to actually happen.

Does that mean it's only there for some specific scenarios and shouldn't
be used in general?

> I'm seeing this PR hung up on process:
> 
> https://github.com/libuv/libuv/pull/1527
> 
> I don't know how much followup work there is. I thought there was a
> CMake issue tracking it, but I don't see one.

IIUC this is about the CPU affinity for child processes?
Looks nice, but in AUTOMOC/UIC it's sufficient to just known which child
processes are running and to get a notification when one has finished.
I think that this level of control is available in libuv already.

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

Re: [cmake-developers] kwsysProcess threadsafety

[Sebastian Holtermann]

On Freitag, 5. Januar 2018 13:00:30 CET clin...@elemtech.com wrote:
> Cool.  I'd like to have parallel automoc and uic.
> 
> How about this 4th option?
> Don't use threads.  A single thread is able to spawn multiple processes, and
> wait on multiple processes, and react when 1 or more processes change
> state.  I'm probably not familiar enough with kwsysProcess to know if this
> approach will work, but it might be easier and simpler(?) than making it
> thread safe.
> 
> Clint
> 

AFAIK there are two interfaces inside CMake that allow to start a process,
kwsysProcess and libuv.

kwsysProcess allows to start a single process and wait for it to finish. I 
thinks it's also possible to start multiple parallel processes.
But there's no interface to select/poll a number of parallel processes.

So the 4th option would boil down to use libuv for process management.

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

[cmake-developers] kwsysProcess threadsafety

[Sebastian Holtermann]

Hello!

As you might have noticed I tried to parallelize AUTOMOC/UIC.
https://gitlab.kitware.com/cmake/cmake/merge_requests/1632
The issue that's blocking it now is that the kwsysProcess framework
isn't thread safe. As a consequence it is not possible for threads to
start processes concurrently using the kwsysProcess framework.

There are three options I see

1) Make kwsysProcess thread safe

I don't think it's impossible but it's not a small task.
Looking through the code I found a few issues that
would block the whole idea for me.
  - OpenVMS: I have little to no knowledge about OpenVMS. 
Wikipedia says it is basically abandoned. 
Can the OpenVMS code be removed? I couldn't test it anyway.

  - C vs. C++
There's a lot of C in processUNIX.c (list allocation etc.).
I would prefer to use C++11 (or higher), especially
std::array, std::vector, std::thread,  std::mutex, etc..
Is C++11 acceptable in kwsysProcess?
This would make processUNIX.c processUNIX.cpp?

2) Use libuv instead

Using the libuv event loop is overkill and would probably imply that
more threads are started than necessary
(the libuv thread pool will be started anyway).
But it would allow to start multiple concurrent  (moc/uic) processes.
Is there a reason to not use libuv?

3) Abandon the idea to parallelize AUTOMOC/UIC

Well, I liked the idea.


Any thoughts?

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

Re: [cmake-developers] CMP0071

[Sebastian Holtermann]

> I find myself setting SKIP_AUTOUIC on *.h and *.cpp files to silence
> CMP0071 warnings. 

It's an unfortunate situation.

In many cases (qt < 5.10) it might work to just let AUTOUIC probe
the (moc/uic/rcc) GENERATED files as well by setting
`cmake_policy(SET CMP0071 NEW)`

-- 

Powered by www.kitware.com

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

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

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

[Sebastian Holtermann]

On Mittwoch, 4. Oktober 2017 20:01:50 CEST clin...@elemtech.com wrote:
> - On Sep 26, 2017, at 9:07 AM, Sebastian Holtermann sebl...@xwmw.org 
wrote:
> >> I updated and I'm getting this:
> >> 
> >> CMake Warning (dev) in claro/navigation5/CMakeLists.txt:
> >> Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED
> >> files.
> >> Run "cmake --help-policy CMP0071" for policy details. Use the
> >> cmake_policy
> >> command to set the policy and suppress this warning.
> >> 
> >> AUTOMOC: Ignoring GENERATED header file(s):
> >> 
> >> "/path/to/ui_SomeFile.h"
> >> "/path/to/qrc_AnotherFile.cpp"
> >> 
> >> 
> >> Those ui_* and qrc_* files do not require processing by moc.
> >> In this case, I was using qt5_wrap_ui() and qt5_add_resources().
> >> 
> >> I did an experiment and replaced qt5_wrap_ui() with autouic, and the
> >> warning went away for those ui_* files.
> >> 
> >> Is there a way to not print out that policy warning on ui_* and qrc_*
> >> files
> >> when using qt5_wrap_ui()/qt5_add_resources()? These are the only file
> >> types
> >> for which I'm getting that warning.
> > 
> > You can set the source file property SKIP_AUTOMOC on the GENERATED files.
> > See: https://cmake.org/cmake/help/v3.9/prop_sf/SKIP_AUTOMOC.html
> > See: https://cmake.org/cmake/help/git-master/policy/CMP0071.html
> > 
> > For example like this
> > ```
> > set_property(SOURCE /path/to/ui_SomeFile.h PROPERTY SKIP_AUTOMOC ON)
> > set_property(SOURCE /path/to/qrc_AnotherFile.cpp PROPERTY SKIP_AUTOMOC ON)
> > ```
> 
> I'm probably pushing things here, but why not.
> I'm experimenting with setting AUTOMOC/AUTOUIC/AUTORCC on, and also using
> the qt5_* macros.
> 
> I see the rcc processing only looks at *.qrc files, but the uic processing
> looks at files with any extension.  Why not limit that to just *.ui files? 
> I find myself setting SKIP_AUTOUIC on *.h and *.cpp files to silence
> CMP0071 warnings.  Its obvious to me that a .cpp or .h file is not an xml
> file as expected by uic.
> 
> I can understand having to set SKIP_AUTOMOC on files with various file
> extensions.
> 
> I bring this up here in case something needs to change on the CMake side.

Despite it's name might imply that, AUTOUIC doesn't care about .ui files in the 
target sources. It never did.

AUTOUIC probes the same files as AUTOMOC, that is .h(xx/pp) and .c(xx/pp) 
files. 
In these files it searches for '#include "ui_.h"' strings and derives the 
.ui file names from that (for uic processing).

I don't think that this can (or should) be changed. It's a reasonable behavior 
and a number of projects rely on it. It just is not what people might expect 
at a first glance.





-- 

Powered by www.kitware.com

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

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

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

[Sebastian Holtermann]

On Montag, 2. Oktober 2017 06:58:31 CEST Brad King wrote:
> On 09/26/2017 12:55 PM, clin...@elemtech.com wrote:
> > https://bugreports.qt.io/browse/QTBUG-63442
> 
> Please take a look at the proposed fix:
> 
>   https://codereview.qt-project.org/#/c/207327/

I dropped a few comments.

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

[Sebastian Holtermann]

On Dienstag, 26. September 2017 11:49:18 CEST Brad King wrote:
> On 09/26/2017 11:15 AM, Sebastian Holtermann wrote:
> > "cmake --help-policy CMP0071" already mentions SKIP_AUTOMOC.
> > Should the warning mention SKIP_AUTOMOC as well?
> 
> Yes, please.  It removes an indirection.

The merge request:
https://gitlab.kitware.com/cmake/cmake/merge_requests/1322

-- 

Powered by www.kitware.com

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

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

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

[Sebastian Holtermann]

On Dienstag, 26. September 2017 11:49:18 CEST Brad King wrote:
> On 09/26/2017 11:15 AM, Sebastian Holtermann wrote:
> > "cmake --help-policy CMP0071" already mentions SKIP_AUTOMOC.
> > Should the warning mention SKIP_AUTOMOC as well?
> 
> Yes, please.  It removes an indirection.

Okay, I got the patch ready but there is a conflict with MR
https://gitlab.kitware.com/cmake/cmake/merge_requests/1307
which needs to be merged first.

-- 

Powered by www.kitware.com

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

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

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

[Sebastian Holtermann]

On Dienstag, 26. September 2017 09:25:36 CEST clin...@elemtech.com wrote:
> - On Sep 26, 2017, at 9:07 AM, Sebastian Holtermann sebl...@xwmw.org 
wrote:
> >> I updated and I'm getting this:
> >> 
> >> CMake Warning (dev) in claro/navigation5/CMakeLists.txt:
> >> Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED
> >> files.
> >> Run "cmake --help-policy CMP0071" for policy details. Use the
> >> cmake_policy
> >> command to set the policy and suppress this warning.
> >> 
> >> AUTOMOC: Ignoring GENERATED header file(s):
> >> 
> >> "/path/to/ui_SomeFile.h"
> >> "/path/to/qrc_AnotherFile.cpp"
> >> 
> >> 
> >> Those ui_* and qrc_* files do not require processing by moc.
> >> In this case, I was using qt5_wrap_ui() and qt5_add_resources().
> >> 
> >> I did an experiment and replaced qt5_wrap_ui() with autouic, and the
> >> warning went away for those ui_* files.
> >> 
> >> Is there a way to not print out that policy warning on ui_* and qrc_*
> >> files
> >> when using qt5_wrap_ui()/qt5_add_resources()? These are the only file
> >> types
> >> for which I'm getting that warning.
> > 
> > You can set the source file property SKIP_AUTOMOC on the GENERATED files.
> > See: https://cmake.org/cmake/help/v3.9/prop_sf/SKIP_AUTOMOC.html
> > See: https://cmake.org/cmake/help/git-master/policy/CMP0071.html
> > 
> > For example like this
> > ```
> > set_property(SOURCE /path/to/ui_SomeFile.h PROPERTY SKIP_AUTOMOC ON)
> > set_property(SOURCE /path/to/qrc_AnotherFile.cpp PROPERTY SKIP_AUTOMOC ON)
> > ```
> 
> Would it make sense for qt5_wrap_ui() and qt5_add_resources() to set
> SKIP_AUTOMOC on the ui_* and qrc_* files?

That would be the best solution. The macros are provided by Qt though and not 
by CMake.


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMP0071

[Sebastian Holtermann]

On Dienstag, 26. September 2017 11:04:30 CEST Brad King wrote:
> On 09/26/2017 09:32 AM, clin...@elemtech.com wrote:
> > CMake Warning (dev) in claro/navigation5/CMakeLists.txt:
> >   Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED
> > files. Run "cmake --help-policy CMP0071" for policy details.  Use the
> > cmake_policy command to set the policy and suppress this warning.
> > 
> >   AUTOMOC: Ignoring GENERATED header file(s):
> > 
> > "/path/to/ui_SomeFile.h"
> > "/path/to/qrc_AnotherFile.cpp"
> > 
> > Those ui_* and qrc_* files do not require processing by moc.
> > In this case, I was using qt5_wrap_ui() and qt5_add_resources().
> > 
> > Is there a way to not print out that policy warning
> 
> Clinton, you can set the SKIP_AUTOGEN source file property on them:
> 
>   https://cmake.org/cmake/help/v3.9/prop_sf/SKIP_AUTOGEN.html
> 
> Sebastian, please revise the policy warning to mention the
> alternatives.

"cmake --help-policy CMP0071" already mentions SKIP_AUTOMOC.
Should the warning mention SKIP_AUTOMOC as well?

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

[Sebastian Holtermann]

> I updated and I'm getting this:
> 
> CMake Warning (dev) in claro/navigation5/CMakeLists.txt:
> Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED files.
> Run "cmake --help-policy CMP0071" for policy details. Use the cmake_policy
> command to set the policy and suppress this warning.
> 
> AUTOMOC: Ignoring GENERATED header file(s):
> 
> "/path/to/ui_SomeFile.h"
> "/path/to/qrc_AnotherFile.cpp"
> 
> 
> Those ui_* and qrc_* files do not require processing by moc.
> In this case, I was using qt5_wrap_ui() and qt5_add_resources().
> 
> I did an experiment and replaced qt5_wrap_ui() with autouic, and the warning
> went away for those ui_* files.
> 
> Is there a way to not print out that policy warning on ui_* and qrc_* files
> when using qt5_wrap_ui()/qt5_add_resources()? These are the only file types
> for which I'm getting that warning.

You can set the source file property SKIP_AUTOMOC on the GENERATED files.
See: https://cmake.org/cmake/help/v3.9/prop_sf/SKIP_AUTOMOC.html
See: https://cmake.org/cmake/help/git-master/policy/CMP0071.html

For example like this
```
set_property(SOURCE /path/to/ui_SomeFile.h PROPERTY SKIP_AUTOMOC ON)
set_property(SOURCE /path/to/qrc_AnotherFile.cpp PROPERTY SKIP_AUTOMOC ON)
```

-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] PRE_BUILD misconception

[Sebastian Holtermann]

Am Donnerstag, 24. August 2017, 07:48:48 CEST schrieb Brad King:
> On 08/23/2017 05:56 PM, Sebastian Holtermann wrote:
> > It seems that in CMake 3.9/AUTOGEN the VS generator uses the *_autogen
> > target more often than necessary (it could use PRE_BUILD instead).
> > 
> > Let's assume a target `B` that depends on
> > 
> >  - a *GENERATED* file `FA`
> >  - a linked library `LA`
> >  - a utility target `TA` (via `add_dependencies()`)
> > 
> > Using the VS generator, will `FA`, `LA` and `TA` be built completely
> > before
> > target B executes it's PRE_BUILD?
> 
> Target-level dependencies will be completely finished, including their
> POST_BUILD if any, before the PRE_BUILD of a dependent target begins.
> In your list above, `LA` and `TA` will definitely be built before `B`
> starts.  For the generated file `FA`, it depends whether the custom
> command is attached to `B` or not.  If it is inside `B` then it won't
> generate until after PRE_BUILD is done.

Okay, thanks.
That will help to fix https://gitlab.kitware.com/cmake/cmake/issues/17205

-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] PRE_BUILD misconception

[Sebastian Holtermann]

It seems that in CMake 3.9/AUTOGEN the VS generator uses the *_autogen
target more often than necessary (it could use PRE_BUILD instead).

Let's assume a target `B` that depends on
 - a *GENERATED* file `FA`
 - a linked library `LA`
 - a utility target `TA` (via `add_dependencies()`)

Using the VS generator, will `FA`, `LA` and `TA` be built completely before
target B executes it's PRE_BUILD?

I'm asking because it's important to know when to PRE_BUILD can be used for 
AUTOGEN.

-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] C++11 all features available?

[Sebastian Holtermann]

> > > > it looks like C++11 is now a requirement for CMake itself.
> > > 
> > > Yes.  We just merged this:
> > >   https://gitlab.kitware.com/cmake/cmake/merge_requests/1132
> > > 
> > > but you beat us to the announcement.
> > 
> > I saw the MR last week and was delighted. The iterator type naming in
> > `for`
> > loops drove me mad.
> 
> Feel free to use `auto`, but you will need to hold off range based for
> loops.

Okay, that's nice.
Just to say, even without auto 

  for (const std::string& item : lst) {
...
  }

is easier to comprehend than

  for (std::vector::const_iterator it = lst.begin();
   it != lst.end(); ++it) {
const std::string& item = *it;
...
  }

which is as C++(98) as can be.

> > > > But does this mean *all* the nice features from the std library can be
> > > > used?
> > > 
> > > Not all.  We're still limited by some of the older C++11 compilers.
> > > We'll have to see how things go on nightly builds.  As limitations
> > > are found they can be documented in `Help/dev/source.rst`.
> 
> Please have a look at the nightly testers on
> https://open.cdash.org/index.php?project=CMake and compare the feature
> availability here: Please see
> http://en.cppreference.com/w/cpp/compiler_support
> 
> Currently CMake is still built with Visual Studio 2010, ie. MSVC 16.0.
> 
> That means we should be able to use auto, nullptr, lambdas, std::array,
> std::function, type traits, trailing return types, r-values, ...

Very nice. C++11 was such a great improvement to the language.
It's much more fun to work with. Even with the slightly limited
feature set available in CMake.

-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] C++11 all features available?

[Sebastian Holtermann]

Am Montag, 21. August 2017, 10:12:26 CEST schrieb Ben Boeckel:
> On Mon, Aug 21, 2017 at 15:53:11 +0200, Sebastian Holtermann wrote:
> >  - std::array
> 
> I don't see why not.
> 
> >  - std::basic_regex (and friends)
> 
> Note that we require backwards compat with the old regex engine, so this
> one needs to be used carefully and only on internal uses.
> 
> >  - std::thread (and friends)
> >  - std::atomic_flag
> 
> CMake uses threads? ;)

Well, a search for "thread" didn't return much.

I was toying with the idea to parallelize Autogen but I couldn't find a proper 
solution that uses the existing target/custom_command primitives.
So why not doing it all in the FOO_autogen target itself, which is a black box 
to the user anyway. Thread pools are an option here. But as mentioned in an 
other post, that would required several of CMake's utility functions to be 
thread safe as well...

-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] C++11 all features available?

[Sebastian Holtermann]

Am Montag, 21. August 2017, 10:04:28 CEST schrieben Sie:
> On 08/21/2017 09:53 AM, Sebastian Holtermann wrote:
> > it looks like C++11 is now a requirement for CMake itself.
> 
> Yes.  We just merged this:
> 
>   https://gitlab.kitware.com/cmake/cmake/merge_requests/1132
> 
> but you beat us to the announcement.

I saw the MR last week and was delighted. The iterator type naming in `for` 
loops drove me mad.

> > But does this mean *all* the nice features from the std library can be
> > used?
> Not all.  We're still limited by some of the older C++11 compilers.
> We'll have to see how things go on nightly builds.  As limitations
> are found they can be documented in `Help/dev/source.rst`.
> 
> We will require std::unique_ptr at least.
> 
> >  - std::array
> 
> I think so but haven't tried it.
> 
> >  - std::basic_regex (and friends)
> 
> We still support GCC 4.8.  IIRC its standard library doesn't have
> the implementations in place.

That's a pitty, because cmsys::RegularExpression isn't thread safe.
Although it might be possible to make it so in a reasonable amount of time

> >  - std::thread (and friends)
> 
> No, at least not yet.  For now we're using libuv's thread primitives
> instead.  Either way anything that needs to build during bootstrap
> may not be able to use this.
> 
> >  - std::atomic_flag

Thread support would be nice because Autogen could be parallelized  perfectly.
Only it would require several utility methods to be thread safe as well. Many 
likely aren't though. I'll have a look at libuv.

-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

[cmake-developers] C++11 all features available?

[Sebastian Holtermann]

Hi, 

it looks like C++11 is now a requirement for CMake itself. That's good news.
But does this mean *all* the nice features from the std library can be used?
I'm especially interested in 

 - std::array
 - std::basic_regex (and friends)
 - std::thread (and friends)
 - std::atomic_flag

-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] AUTOGEN per-config sources

[Sebastian Holtermann]

Am 17.07.2017 um 16:20 schrieb Brad King:
> On 07/15/2017 08:37 PM, comic fans wrote:
>> recent commits shows that QtAutogen is moving to create suffixed files
>> and folders for different config, but with this commit,
>> my generator test failed on Qt5Autogen as following:
>>
>> Target "rccDepends" has source files which vary by configuration.  This is
>>  not supported by the "Fastbuild" generator.
>>
>>  Config "Debug":
>>
>>/working/CMake/Tests/QtAutogen/rccDepends/main.cpp
>>/working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res1.qrc
>>/working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res2.qrc
>>
>> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res1_Debug.cpp
>>
>> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res2_Debug.cpp
>>
>>  Config "Release":
>>
>>/working/CMake/Tests/QtAutogen/rccDepends/main.cpp
>>/working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res1.qrc
>>/working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res2.qrc
>>
>> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res1_Release.cpp
>>
>> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res2_Release.cpp
>>
>> How should I make my generator compatible with this ? or this feature
>> didn't complete ,I should wait it complete ?
> 
> The goal for Qt AUTOGEN features is to have the generated files use
> per-config locations in multi-config generators.  However, our
> multi-config generators don't all fully support per-config sources yet.
> Your new generator should do so if possible. See GetAllConfigSources
> in cmGeneratorTarget.
> 
> Sebastian, FYI comic fans is working on a new multi-config generator.

It might be better to whitelist generators in
AUTOGEN to use per-config sources than blacklisting them.
I'll have another look at it later.

-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] Making your regular expression engine more reliable

[Sebastian Holtermann]

Am 18.05.2017 um 23:07 schrieb Domen Vrankar:
> 2017-05-18 21:44 GMT+02:00 Alan W. Irwin  >:
> 
> I have just discovered a long-standing regular expression bug (see
>  >) that has been
> around since at least 3.0.2.
> 
> So your unit tests for regular expressions obviously missed at least
> this issue. I have no idea what those unit tests are (or even if they
> exist), but one possibility for attempting to wring most of the bugs out
> of your regular expression processor is to adapt some other project's
> regexp test suite. See
> 
>  
> >
> for a rather large list of such test suites.
> 
> Another possibility is simply to forget supporting your own regexp
> engine and adopt someone else's very well regarded regexp engine (such
> as libprng).  I vaguely recall that has been suggested before, but
> since that hasn't happened I presume inertia or NIH syndrome won or
> else there was some strong reason why you didn't go that route.
> 
> 
> There's a third option that comes to mind - I remember that a while back
> there was talk about TR1 becoming a requirement for building CMake so
> TR1 regex library could be exposed (probably just |ECMAScript version).

+1

There are more limitations in the current regexp implementation.

1) It uses global variables that store only the result of
   the latest evaluation. This makes it impossible to access the
   matches of two or more cmsys::RegularExpression instances.

2) Because of the global variables cmsys::RegularExpression
   is not thread safe.

There are no threads used in CMake as far as I can tell
from a quick code search.
But there are some places in the AUTOGEN parts that could be
parallelized if regular expressions were thread safe (and threads
were available in CMake).

-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] source_group and generator expressions

[Sebastian Holtermann]

>> Would TARGETNAME_autogen/moc_compilation_$.cpp work with the
>> current state of VS and XCode? The file name is pretty much unique.
> 
> Yes, though some work would still be needed to add the right exclusion
> code to Xcode.

Good, I'll stick with that name then.
For the rcc generated files the situation is similar.

I wonder if the $ based file names should be the default even
for single configuration generators. It would make the code and
documentation easier to maintain/comprehend.

Anyway I'll upload the branch with the AUTOGEN changes soon.
Maybe you guys can use it as test case for the XCode changes then.

>> AUTOGEN generated files the properties "GENERATED" and "SKIP_AUTOGEN"
>> must be set. This requires access to the cmSourceFile which is not
>> available when using the $ generator expression in the current
>> cmGeneratorTarget::AddSource.
> 
> Use cmMakefile::GetOrCreateSource for each of the per-config names
> (and no generator expression) to get a `cmSourceFile*` and set its
> properties.  Then add the source to the target with the generator
> expression in its name.  The generators should match them up properly.

Good, that's exactly what I did already but I wasn't sure if it was
going to work.

>> Also cmGeneratorTarget::AddIncludeDirectory with configuration parameter
>> would be required to pass per configuration include directories.
> 
> Pass include directories that contain generator expressions to filter
> or name by configuration.

Okay.

-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] source_group and generator expressions

[Sebastian Holtermann]

Am 16.05.2017 um 15:11 schrieb Brad King:
> On 05/16/2017 05:52 AM, Sebastian Holtermann wrote:
>> There are two ways to achieve this
>> 1) Put TARGETNAME_autogen/$/moc_compilation.cpp
>>into AUTOGEN_SOURCE_GROUP
>>- Requires gen. exp. support in source_group
>>
>> 2) Manually replace $ for all configurations and put all
>>variants into the AUTOGEN_SOURCE_GROUP
>>- Does not require gen. exp. support in source_group
>>- May flood the source_group with files from an other configurations?
>>  Are source groups even configuration aware?
>>
>> I'd prefer 1) but does source_group support generator expressions?
> 
> I don't think so, but it could be taught to do so.  The main challenge
> is supporting per-configuration sources, and that would have to be
> solved for either approach.

I thought per configuration source were supported already :/.

> Source groups are used in IDE generators to organize source files.
> The IDE project file formats tend to not have the Configuration
> as a parameter to their source groups.  Instead all sources for
> all configurations get listed and then individual sources can be
> marked with conditions on a per-configuration basis.
> 
> Recently I refactored the VS generators to support per-config
> source generation (via per-config exclusion rules).  Currently
> it is limited somewhat artificially but the main generation
> infrastructure is there.
> 
> OTOH the Xcode generator does not have a good way to do per-config
> source files.  It has very limited support for excluding source
> files on a per-config basis but only by the *file name* ignoring
> the directory.

Okay, that would disallow
TARGETNAME_autogen/$/moc_compilation.cpp because of the
non-unique file name.

Would TARGETNAME_autogen/moc_compilation_$.cpp work with the
current state of VS and XCode? The file name is pretty much unique.

Or maybe using $ is not the best idea at all.
Much more useful in this AUTOGEN case (and maybe easier to implement?)
would be a cmGeneratorTarget::AddSource method that takes a second
configuration parameter. In fact that would be ideal because on the
AUTOGEN generated files the properties "GENERATED" and "SKIP_AUTOGEN"
must be set. This requires access to the cmSourceFile which is not
available when using the $ generator expression in the current
cmGeneratorTarget::AddSource.
Also cmGeneratorTarget::AddIncludeDirectory with configuration parameter
would be required to pass per configuration include directories.

Having the two methods available is the best solution I can see at the
moment. I can't do that though, my understanding of the CMake generators
is too limited for that.

- 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

[cmake-developers] source_group and generator expressions

[Sebastian Holtermann]

Hi, I'm working on a fix for
https://gitlab.kitware.com/cmake/cmake/issues/16460
which requires putting a generator expression into a source group,
namely $

The background is that
TARGETNAME_autogen/$/moc_compilation.cpp (and others)
should go into the source_group AUTOGEN_SOURCE_GROUP.

There are two ways to achieve this
1) Put TARGETNAME_autogen/$/moc_compilation.cpp
   into AUTOGEN_SOURCE_GROUP
   - Requires gen. exp. support in source_group

2) Manually replace $ for all configurations and put all
   variants into the AUTOGEN_SOURCE_GROUP
   - Does not require gen. exp. support in source_group
   - May flood the source_group with files from an other configurations?
 Are source groups even configuration aware?

I'd prefer 1) but does source_group support generator expressions?

-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] QtAutogen suggestions

[Sebastian Holtermann]

Am 28.11.2016 um 17:00 schrieb Brad King:
> On 11/28/2016 10:25 AM, Sebastian Holtermann wrote:
>> I'm going ahead then.
> 
> Thanks.  BTW, please sign up for a gitlab.kitware.com account
> (optionally via GitHub OAuth) so that we can include you in
> discussion of related issues.  For example:

https://gitlab.kitware.com/sebholt

-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] QtAutogen suggestions

[Sebastian Holtermann]

Am 28.11.2016 um 15:57 schrieb Brad King:
> On 11/25/2016 05:37 PM, Sebastian Holtermann wrote:
>> There are some issues with QtAutogen that still bother me and
>> that I would like to change.
> 
> Great!  We currently have no dedicated maintainer for it and I have
> little understanding of the tools and use cases associated with it
> myself.  It will be useful to have your help.

Okay.

>> 1) Most files get generated in
>> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.dir
>>
>> Is the ".dir" suffix neccessary? I think is should be removed.
> 
> That suffix is the convention used for all intermediate files
> (e.g. object files) associated with a particular target of any kind.
> The _automoc targets are simply following that convention, but there
> is no strong reason this has to be the case for the generated sources.

Okay, I'm going to remove it then in this place.
It is easier to read IMO.

>> 2) Moc files that are manually included by a
>> #include "moc_.cpp"
>> statement get generated in ${CMAKE_CURRENT_BINARY_DIR}
>>
>> A better solution would be to generate the moc_.cpp files in
>> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc/include.
>> AUTOMOC then should automatically add that directory to the
>> INCLUDE_DIRECTORIES of the origin target.
> 
> Yes, I think that has been discussed before but no one ever implemented it.
> 
>> 3) The mocs compilation file currently gets generated as
>> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.cpp
>>
>> The file could be generated as
>> ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc/compilation.cpp
> 
> Okay.
> 
>> 4) AUTOMOC AUTOUIC and AUTORCC perform different independent tasks that
>> in the current implementation get processed serially inside a single
>> custom target named ${TARGETNAME}_automoc.
>>
>> I think each of the three could be handled in an own target.
> 
> In VS IDE and Xcode each target becomes another user-visible entity so
> we try to keep generated targets to a minimum.  IIRC in some cases we
> even try to use a PRE_BUILD step in the VS targets to avoid an extra
> target altogether.  The breakdown could be made generator-specific
> to improve behavior on Ninja and Makefile generators.  In the case that
> a common target is needed it could be renamed to `_autogen` instead.

For VS tries to use PRE_BUILD when possible for all other generators
a custom target is used. I took that from the source but I'm not
familiar with VS and can't test any changes.
It safer to leave this the way is is for now.

I'm going ahead then.

-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

[cmake-developers] QtAutogen suggestions

[Sebastian Holtermann]

Hi.

There are some issues with QtAutogen that still bother me and
that I would like to change.


1) Most files get generated in
${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.dir

Is the ".dir" suffix neccessary? I think is should be removed.


2) Moc files that are manually included by a
#include "moc_.cpp"
statement get generated in ${CMAKE_CURRENT_BINARY_DIR}

This is not ideal because
- ${CMAKE_CURRENT_BINARY_DIR} must be added to the
  INCLUDE_DIRECTORIES manually in CMakeLists.txt
- Multiple targets may write divergent content
  concurrently to the same moc_.cpp file.

A better solution would be to generate the moc_.cpp files in
${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc/include.
AUTOMOC then should automatically add that directory to the
INCLUDE_DIRECTORIES of the origin target.

The same issue is present for AUTOUIC btw. which generates header files
in ${CMAKE_CURRENT_BINARY_DIR}. It could be adapted in the same way.


3) The mocs compilation file currently gets generated as
${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.cpp

The file could be generated as
${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc/compilation.cpp

This way and along with the changes in 2) all files would be generated in
${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc.
This is nice and contained and allows perfect cleanup by adding
the directory to ADDITIONAL_MAKE_CLEAN_FILES.
The moc/uic cleanup is broken/incomplete in CMake 3.7 btw..


4) AUTOMOC AUTOUIC and AUTORCC perform different independent tasks that
in the current implementation get processed serially inside a single
custom target named ${TARGETNAME}_automoc.

I think each of the three could be handled in an own target.
Then instead on one custom target there would be three custom targets:
- ${TARGETNAME}_automoc
- ${TARGETNAME}_autouic
- ${TARGETNAME}_autorcc
Also each target would generate all files in an own directory:
- ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_automoc
- ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_autouic
- ${CMAKE_CURRENT_BINARY_DIR}/${TARGETNAME}_autorcc

Once in place this would also be easier to maintain compared to now
where all three target logics are mixed together in a single C++ class.



Please share your opinion on the points.
If there is no fundamental opposition I will simply
go ahead and work on the patches.

-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] Current deficiencies of automoc

[Sebastian Holtermann]

Am 14.11.2016 um 12:41 schrieb Alan W. Irwin:
> On 2016-11-14 09:06+0100 Sebastian Holtermann wrote:
> 
>> What probably could be done is to add
>> ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir
>> to the INCLUDE_DIRECTORIES of the target and then generate all
>> #included moc file there, accepting the risk of intra target name
>> collisions.
> 
> Hi Sebastian:
> 
> Your compromise idea above sounds good to me!
> 

Btw. I liked your
${CMAKE_BINARY_DIR}/
${TARGETNAME}_automoc.dir/
${HEADERPATHCHECKSUM}/
moc_${HEADERNAME}.cpp
approach.

It could be used for the moc_.cpp files that are not
manually #included and therefore can have any name.

Over the current
${CMAKE_BINARY_DIR}/
${TARGETNAME}_automoc.dir/
moc_${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp
scheme it has the advantages that
1) moc_.cpp files are grouped by their source directory
2) ${HEADERNAME} is kept intact and does not get shortened
3) fewer weird looking checksum names ;)

1) and 2) are generally helpful to find and debug moced files I think.

There are a some other changes to the automoc system I would like to
propose / work on. I'm currently busy with an other project though.

-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] Current deficiencies of automoc

[Sebastian Holtermann]

Am 13.11.2016 um 07:48 schrieb Alan W. Irwin:
> On 2016-10-22 19:49+0200 Sebastian Holtermann wrote:
> 
> [...]
>> Actually I made an implementation in 3.6.0 that generated the moc files
>> in the a build tree subdirectory correspoding to the header path.
>> But that blew up on some projects because the generated paths got too
>> long for some compiĺers. That implementation was theefore reverted.
>> In 3.7  there is a new approatch that generates the moc files in
>> ${CMAKE_BINARY_DIR}/
>>${TARGETNAME}_automoc.dir/
>>${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp
>> This ensures that the paths don't get too long and that there won't be
>> any name collisions.
> 
> Hi Sebastian:
> 
> After a substantial break to finish off a different project, I have
> now had a chance to return to the present topic using my attached
> test_automoc project.  (Also available in the cmake/test_automoc
> subdirectory of the PLplot git master branch that can be accessed at
> <https://sourceforge.net/p/plplot/plplot/ci/master/tree/>.) The
> project builds 6 separate simple Qt5 applications that #include a
> header that needs moc processing.  The only differences between the
> source code files for the various executables is the name and
> directory location of that #include'd file and the various instructions
> given to automoc (and in one case qt5_wrap_cpp) to process that file.
> 
> With that test project, I now confirm (sorry about the noise to the
> contrary before) that automoc does use the approach you mentioned
> above for CMake-3.7.0 to reduce the name collisions that occur for
> that same project for earlier versions of CMake.
> 
> Concerning the collisions still expected for 3.7.0, the automoc
> documentation (see
> <https://cmake.org/cmake/help/v3.7/prop_tgt/AUTOMOC.html>) states the
> following:
> 
> "However, if multiple source files in different directories do this
> [i.e., contain an "#include "moc_.cpp" when the header
> name is .h] then their generated moc files would
> collide. In this case a diagnostic will be issued."
> 
> For the life of me, I cannot find a way to generate that diagnostic.
> Instead, three different targets (two targets concerning the same
> implementation code and header in the same directory and a third
> target for a copy of that same implementation code and header in a
> different directory) generate at build time a file named
> moc_test_q_object.cpp in the same build directory at different times.
> This is a clear example of a three-way name collision, but CMake does
> not issue a diagnostic for any of these targets concerning that
> collision contrary to the above documentation.
> 
> Could you please take a look at the three last executables configured
> for this test case (helloworld_automoc_same_include,
> helloworld_automoc_same_include1, and
> helloworld_automoc_same_include2) to see why that collision diagnostic
> is not being issued with cmake-3.7.0?  Better yet, of course, would be
> to solve these remaining name collisions completely by using a
> modification of your idea above, i.e., for this special case where
> users implementation code contained
> 
> #include "moc_.cpp"
> 
> then moc should generate the file
> 
> ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM}/moc_${HEADERNAME}.cpp
> 
> 
> Note, the generated moc file has the name expected by the #include so
> I believe this idea would work so long as automoc automatically
> appended
> ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM} to
> the target INCLUDE_DIRECTORIES property.
> 

Hi Alan,

the automoc diagnostic checks for name collisions within a single target
only, not across multiple targets - as in your example.

The problem I see is that all moc files included by the
#include "moc_.cpp"
scheme get generated in ${CMAKE_BINARY_DIR}.
It would be better to generate them in
${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir
to avoid inter target name collisions.
Your solution using the path checksum as well would be event better
as it avoids name collisions even within a target.
The problem there is though that it would require to add
a .cpp file specific -I compiler statement for every .cpp file
that includes a moc file.
This is hard to do with the current automoc implementation.
I would not want to do it.
What probably could be done is to add
${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir
to the INCLUDE_DIRECTORIES of the target and then generate all
#included moc file there, accepting the risk of intra target name
collisions.

-Sebastian

-- 

Powered by www.kitware.com

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

Kitwar

Re: [cmake-developers] Current deficiencies of automoc

[Sebastian Holtermann]

Am 21.10.2016 um 13:39 schrieb Alan W. Irwin:

On 2016-10-21 09:42+0200 Sebastian Holtermann wrote:

[...]

Hi!

I tried your example.
It isn't complete, test_q_object.h needs an
   #include 
and a constructor/destructor definition, e.g.:
   MyClass(QObject *parent = 0) {;}
   ~MyClass(){;}


Hi Sebastian:

Thanks for that fix which indeed solves the linking issue.



With regards to automoc the
   #include "moc_test_q_object.cpp"
in the end should not be neccessary since
   #include "test_q_object.h"
already references to the header.
The problem is that this reference is not a direct path from the
source file but relies on include_directories.
CMake does not seem to populate automoc's scan list with files
from include_directories.
I tried to figure out why but this is quite complex.


I hope you are able to fix this along the lines I have mentioned
(which includes putting all generated results in the build tree
corresponding to the header) since using #include
"moc_test_q_object.cpp" in main.cpp is currently the only documented
way to use automoc (see, e.g.,
<https://cmake.org/cmake/help/v3.6/prop_tgt/AUTOMOC.html>).


As Sascha Cunz pointed out well, it is problematic to simply automoc any 
header found in the include_directories. I think the current behaviour 
is reasonable good. The documentation could be improved though to 
mention the fullpath method.




In sum, I hope you are willing to fix the currently documented automoc
"#include" method so it puts all generated results in the build tree
corresponding to the header, update the automoc documentation so you
also mention the "fullpath" alternative, and also similarly fix that
method so the location of the two generated files is in the build
directory corresponding to the header rather than the build directory
corresponding to the source file.


Actually I made an implementation in 3.6.0 that generated the moc files
in the a build tree subdirectory correspoding to the header path.
But that blew up on some projects because the generated paths got too 
long for some compiĺers. That implementation was theefore reverted.

In 3.7  there is a new approatch that generates the moc files in
${CMAKE_BINARY_DIR}/
${TARGETNAME}_automoc.dir/
${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp
This ensures that the paths don't get too long and that there won't be 
any name collisions.



My apologies for making suggestions for improvement without being able
to help you with the implementation (except testing of results), but
my C++ skills and CMake developer skills are just not up to it (as you
could probably tell from the required test_q_object.h fix you had to
suggest.)


We'll I'm just a spare time contributor but it's motivating to see that 
someone cares about these issues as well.


-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] Current deficiencies of automoc

[Sebastian Holtermann]

Am 21.10.2016 um 01:29 schrieb Alan W. Irwin:

On 2016-10-20 15:08-0400 Brad King wrote:


Please construct a minimal/complete example source tree/tarball
that demonstrate the layout you'd like to have work.  That will
be helpful in constructing such a bug report.


OK. I have attached the requested minimal example to serve as the
basis for further discussion.  The files in the tarball are

test_qt5/
test_qt5/include/
test_qt5/include/test_q_object.h
test_qt5/main.cpp
test_qt5/CMakeLists.txt

include/test_q_object.h is a header that contains a minimal use of
Q_OBJECT.  (Likely too minimal so I will need help with that see below.)
main.cpp is a "hello-world" example that #includes that header.  It also
#includes
the moc-generated moc_test_q_object.cpp.

The USE_AUTOMOC option for this test project defaults to OFF.  In that
default case this test project is set up so that the qt5_wrap_cpp is
called instead of using automoc, and the
result is the compilation works fine (all headers and files generated
by moc are found with no issues) but there is a link error

CMakeFiles/helloworld.dir/main.cpp.o:(.data.rel.ro._ZTV7MyClass[_ZTV7MyClass]+0x28):

undefined reference to MyClass::~MyClass()'

which likely has to do with include/test_q_object.h being too minimal.
I would appreciate help with that issue to complete this example, but
that is a side issue and the principal result is the compile (as
opposed to the link) was a success with the default -DUSE_AUTOMOC=OFF.

However, if you try -DUSE_AUTOMOC=ON with this project the compile
step (before it even gets to the link step) fails as follows:

Automatic moc for target helloworld
/home/software/cmake/install-3.5.2/bin/cmake -E cmake_autogen
/home/software/plplot/HEAD/test_qt5/build_dir/CMakeFiles/helloworld_automoc.dir/
""
AUTOGEN: Checking /home/software/plplot/HEAD/test_qt5/main.cpp
AUTOGEN: error: /home/software/plplot/HEAD/test_qt5/main.cpp The file
includes the moc file "moc_test_q_object.cpp", but could not find header
"test_q_object{.h,.hh,.h++,.hm,.hpp,.hxx,.in,.txx}" in
/home/software/plplot/HEAD/test_qt5/

I hope a simple solution to this deficiency of the current automoc can
be found using the following ideas (copied from my previous post to
keep this self-contained).

If

#include "moc_.cpp"

is found in a source file under automoc
control, then if moc_.cpp could not be found in any of the
include directories for the target, then search those include
directories (including source-tree equivalents of build-tree include
directories) for .h, run moc on that file and place the result
moc_.cpp in the build directory corresponding to .

So the result is moc would be run just once on the correct header file
with the moc_.cpp result stored in one logical location no
matter how many different source files in different directories have
code with the above #include.

Alan
__
Alan W. Irwin


Hi!

I tried your example.
It isn't complete, test_q_object.h needs an
#include 
and a constructor/destructor definition, e.g.:
MyClass(QObject *parent = 0) {;}
~MyClass(){;}

With regards to automoc the
#include "moc_test_q_object.cpp"
in the end should not be neccessary since
#include "test_q_object.h"
already references to the header.
The problem is that this reference is not a direct path from the
source file but relies on include_directories.
CMake does not seem to populate automoc's scan list with files
from include_directories.
I tried to figure out why but this is quite complex.

A quick fix for the example would be to explicitly add the
headers-to-moc to the sources list.
- add_executable(helloworld main.cpp)
+ add_executable(helloworld main.cpp
+   ${CMAKE_SOURCE_DIR}/include/test_q_object.h)

The #include "moc_test_q_object.cpp" in main.cpp can be removed then.

-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] QtAutogen: Patches to allow empty .qrc files

[Sebastian Holtermann]

Am 30.09.2016 um 16:17 schrieb Brad King:

On 09/30/2016 05:38 AM, Sebastian Holtermann wrote:

Here are some small patches that fix the issue and add a test case.


Thanks.  I've applied the patches with minor tweaks:

 QtAutogen: Allow .qrc files that do not contain any file reference
 https://gitlab.kitware.com/cmake/cmake/commit/98b11f25

 QtAutogen: Add test for empty qrc file
 https://gitlab.kitware.com/cmake/cmake/commit/bcafc399

 QtAutogen: Use cmSystemTools::Error instead of std::cerr
 https://gitlab.kitware.com/cmake/cmake/commit/a189d019

-Brad



Thanks.

-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] QtAutogen: Use Base32 instead of Base64 for file names

[Sebastian Holtermann]

Am 30.08.2016 um 16:53 schrieb Brad King:

On 08/28/2016 10:00 AM, Sebastian Holtermann wrote:

Base32 is a better choice IMO because it is single case and does not
generate disruptive characters like '_', '-' or '/'.

Here are two patches that replace Base64 with Base32.


Thanks.  Please revise the Base32 infrastructure to simply be
in CMake instead of KWSys.



The patches.

-Sebastian



cmake_3-6-1_autogen_patches_base32_v002.tar.gz
Description: application/gzip
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] QtAutogen: Use Base32 instead of Base64 for file names

[Sebastian Holtermann]

Hello again.

I think there are some issues when using Base64 checksum for filenames.
- They look weird/ugly with random cases an  '_' and '-' characters
  mixed in
- On cases insensitive filesystems mixed case names may cause
  problems (e.g. undetected name collisions)

Base32 is a better choice IMO because it is single case and does not 
generate disruptive characters like '_', '-' or '/'.


Here are two patches that replace Base64 with Base32.

Please review.

Kind regards,
-Sebastian


cmake_3-6-1_autogen_patches_base32_v001.tar.gz
Description: application/gzip
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] QtAutogen 3.6.0 directory nesting overflow patch

[Sebastian Holtermann]

Am 10.08.2016 um 19:33 schrieb Brad King:

On 08/10/2016 06:15 AM, Sebastian Holtermann wrote:

These patches change the private abstract interface of cmCryptoHash to
return std::vector instead of std::string.
Conversion to std::string is handled by a static public method.


Nice.  I've added this to the topic, now merged for testing here:

 Merge topic 'autogen-same-name' into next
 https://cmake.org/gitweb?p=cmake.git;a=commit;h=df237068


Thanks!


Now all this topic is missing is an update to the documentation
to explain the behavior w.r.t. duplicate file names versus the
symbol names.



Like this?

-Sebastian

>From c2800c2259a69ceb93f7a28829ab46cfe9b5bc27 Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann <sebh...@xwmw.org>
Date: Mon, 15 Aug 2016 09:07:36 +0200
Subject: [PATCH] AUTORCC documentation extended for same .qrc name case

---
 Help/prop_tgt/AUTORCC.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/Help/prop_tgt/AUTORCC.rst b/Help/prop_tgt/AUTORCC.rst
index 8dce6b1..4281fc4 100644
--- a/Help/prop_tgt/AUTORCC.rst
+++ b/Help/prop_tgt/AUTORCC.rst
@@ -19,5 +19,9 @@ Additional command line options for rcc can be set via the
 The global property :prop_gbl:`AUTOGEN_TARGETS_FOLDER` can be used to group
 the autorcc targets together in an IDE, e.g. in MSVS.
 
+When there are multiple ``.qrc`` files with the same name, CMake will generate
+custom unique names for ``rcc``. Therefore if ``Q_INIT_RESOURCE()`` or
+``Q_CLEANUP_RESOURCE()`` need to be used the ``.qrc`` file name must be unique.
+
 See the :manual:`cmake-qt(7)` manual for more information on using CMake
 with Qt.
-- 
2.8.1

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] QtAutogen 3.6.0 directory nesting overflow patch

[Sebastian Holtermann]

Okay.  Please look at extending cmCryptoHash to offer access to
the _Final functions to get the binary digests directly as
`std::vector` or something like that.  That will
avoid the binary->hex->binary conversion sequence before going
to Base64.  Also, please explain the motivation in comments.


These patches change the private abstract interface of cmCryptoHash to 
return std::vector instead of std::string.

Conversion to std::string is handled by a static public method.

-Sebastian




cmake_3-6-1_cmCryptoHash_patches_v001.tar.gz
Description: application/gzip
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] QtAutogen 3.6.0 directory nesting overflow patch

[Sebastian Holtermann]

Am 09.08.2016 um 17:52 schrieb Brad King:

On 08/09/2016 11:45 AM, Sebastian Holtermann wrote:

In the non-unique-qrc-name case the checksum is hard to reproduce for a
user. In this case I'd say CMake does not make any guaratees for
  - the actual symbol name
  - the symbol name to not change in the future
It only guarantees the symbol to be unique within the project.

If the user really needs a guranteed symbol name, e.g. for a library,
he/she has to ensure that the BASENAME.qrc file name is unique within
the project. In CMake 3.5 this was a requirement anyway.


Okay.  Please update the documentation accordingly.


Why does cmFilePathUuid::GetChecksumString go through so many steps
of transformation?  Why not just take the original hex-valued hash
and use it directly (possibly truncated)?


Base64 uses 64 different characters. Hex values only 16.

I'm not tied to Base64 but I think it provies the best uniqueness
with respect to the file-length and allowed-characters limitations.


Okay.  Please look at extending cmCryptoHash to offer access to
the _Final functions to get the binary digests directly as
`std::vector` or something like that.  That will
avoid the binary->hex->binary conversion sequence before going
to Base64.  Also, please explain the motivation in comments.



I'll look into it within the next days.

-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] QtAutogen 3.6.0 directory nesting overflow patch

[Sebastian Holtermann]

Am 09.08.2016 um 16:11 schrieb Brad King:

On 08/08/2016 04:19 PM, Sebastian Holtermann wrote:

It is back to what it was in 3.5 for the all-qrc-names-unique case.
So yes, existing projects get the same symbol name they used to get.


Good, thanks.


New projects that now can use non unique file names
may get a symbol name based on the checksum extended file name
- but that one is also length limited and should be safe.


Is this checksum user-facing in that they may need to reference such
a symbol in their own code by this name?  This would restrict us from
ever changing the hash algorithm in the future.


Well, it is user-facing.
Though for one-binary applications the user never needs
to know the the actual symbol name. Only when building libraries.

It is said n "Using Resources in a Library" in
http://doc.qt.io/qt-5/resources.html
--
Note: The use of Q_INIT_RESOURCE() and Q_CLEANUP_RESOURCE() is not 
necessary when the resource is built as part of the application.

--

In the non-unique-qrc-name case the checksum is hard to reproduce for a 
user. In this case I'd say CMake does not make any guaratees for

 - the actual symbol name
 - the symbol name to not change in the future
It only guarantees the symbol to be unique within the project.

If the user really needs a guranteed symbol name, e.g. for a library, 
he/she has to ensure that the BASENAME.qrc file name is unique within 
the project. In CMake 3.5 this was a requirement anyway.




But I found another issue.
The checksum string generator may generate a '-' in the file name.
This is allowed for file names but not for symbol names.
I have attached a small patch to fix this.


Thanks, I squashed that in.

Why does cmFilePathUuid::GetChecksumString go through so many steps
of transformation?  Why not just take the original hex-valued hash
and use it directly (possibly truncated)?


Base64 uses 64 different characters. Hex values only 16.
Using Base64 the 14 character checksum string allows 64**14
different combinations versus 16**14 combinations when using hex.
Therefore a checksum collision is less likely when using Base64.

I'm not tied to Base64 but I think it provies the best uniqueness
with respect to the file-length and allowed-characters limitations.

-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] QtAutogen 3.6.0 directory nesting overflow patch

[Sebastian Holtermann]

Am 08.08.2016 um 19:40 schrieb Brad King:

On 08/06/2016 09:42 AM, Sebastian Holtermann wrote:

Ok, here is a new set of patches based on the current git master branch.


Thanks!


+outStream << "#include \""
+  << cmsys::SystemTools::ConvertToOutputPath(it->second)
+  << "\"\n";


The ConvertToOutputPath method may also add its own double quotes.
It is not just about slash conversion.  Please use another approach
to convert slashes.  I dropped this patch for now.


Ok, I just checked
http://stackoverflow.com/questions/5790161/is-the-backslash-acceptable-in-c-and-c-include-directives
It is even invalid to use backslashes in an #include statements.

The paths are generated with a forward slash
so it should be good to just use them as they are.


Meanwhile I've applied the rest:

 cmFilePathUuid: Add class to generate deterministic unique file names
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ecb6df52

 QtAutogen: Use std:: instead of ::std::
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=06217388

 QtAutogen: Allow multiple moc files with the same name
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3e2cd04b

 QtAutogen: Allow multiple qrc files with the same name
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=71d0308a

 Tests/QtAutogen: Test same moc/qrc source names in different directories
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20f0028c

and merged to `next` for testing.


Great, thanks.


One of the problems reported in

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

with the previous approach was that the symbol name created by autorcc
changed from what it was in CMake <= 3.5.  Is it now preserved?


It is back to what it was in 3.5 for the all-qrc-names-unique case.
So yes, existing projects get the same symbol name they used to get.

New projects that now can use non unique file names
may get a symbol name based on the checksum extended file name
- but that one is also length limited and should be safe.

But I found another issue.
The checksum string generator may generate a '-' in the file name.
This is allowed for file names but not for symbol names.
I have attached a small patch to fix this.

-Sebastian

>From 35aa83b165fd6b69694c9cfe264b9d18d86de3ab Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann <sebh...@xwmw.org>
Date: Mon, 8 Aug 2016 20:58:21 +0200
Subject: [PATCH] QtAutogen: Replace invalid character for symbol names

---
 Source/cmQtAutoGenerators.cxx | 4 
 1 file changed, 4 insertions(+)

diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index 6a95615..063c355 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -1331,6 +1331,10 @@ bool cmQtAutoGenerators::GenerateQrc(const std::string& qrcInputFile,
 // Remove "qrc_" at string begin
 symbolName.erase(0, 4);
   }
+  // Replace '-' with '_'. The former is valid for
+  // file names but not for symbol names.
+  std::replace( symbolName.begin(), symbolName.end(), '-', '_' );
+
   const std::string qrcBuildFile = this->Builddir + qrcOutputFile;
 
   int sourceNewerThanQrc = 0;
-- 
2.8.1

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] QtAutogen 3.6.0 directory nesting overflow patch

[Sebastian Holtermann]

Am 02.08.2016 um 19:09 schrieb Brad King:

On 07/31/2016 03:56 PM, Sebastian Holtermann wrote:

I have updated the patch for CMake 3.6.0 to fix
https://gitlab.kitware.com/cmake/cmake/issues/16209

Here is an updated patch.


Thanks.  However, it is too late to restore this change for the 3.6
series.  3.6.1 reverted the change.  We can re-introduce it for 3.7
so that it can go through another round of release candidates.


Fair enough.


Please rebase on `master` and include all needed changes as if this
change were being made for the first time, including the restoration
of the tests.


Ok, here is a new set of patches based on the current git master branch.
I have also renamed the "same_name" test to "sameName" since camel case 
seems most common in CMake.


-Sebastian



cmake_3-6-1_autogen_patches_v001.tar.gz
Description: application/gzip
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] QtAutogen 3.6.0 directory nesting overflow patch

[Sebastian Holtermann]

Am 31.07.2016 um 18:49 schrieb Sebastian Holtermann:

Hi,

I have updated the patch for CMake 3.6.0 to fix
https://gitlab.kitware.com/cmake/cmake/issues/16209
This patch introduces a new class cmFilePathUuid which
is used in QtAutogen to generated unique filenames.
The name generation algorithm is the same as in
http://public.kitware.com/pipermail/cmake-developers/2016-July/029087.html
but the paths initialization moved to the class constructor
- which also accepts a cmMakefile pointer.

Please review.


There was a path conversion missing.
Here is an updated patch.

-Sebastian


>From dab8f01d2ba5a592f5b3c3d3b73e62d23545f397 Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann <sebh...@xwmw.org>
Date: Tue, 26 Jul 2016 16:39:12 +0200
Subject: [PATCH] QtAutogen fix for too deep nested directory generation.

Instead of generating moc_* and qrc_* files in subdirectories
that reflect their source's location in the source tree
the files get generated solely in the TARGET_NAME_automoc.dir/
but get a Base64 encoded checksum suffix that was generated
from their source path and a few more seed strings.
---
 Source/CMakeLists.txt   |   1 +
 Source/cmFilePathUuid.cxx   | 162 
 Source/cmFilePathUuid.h |  70 ++
 Source/cmQtAutoGeneratorInitializer.cxx |  76 +++
 Source/cmQtAutoGenerators.cxx   | 123 +++-
 Source/cmQtAutoGenerators.h |   4 +-
 6 files changed, 300 insertions(+), 136 deletions(-)
 create mode 100644 Source/cmFilePathUuid.cxx
 create mode 100644 Source/cmFilePathUuid.h

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 3223831..645542c 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -238,6 +238,7 @@ set(SRCS
   cmFileLockPool.h
   cmFileLockResult.cxx
   cmFileLockResult.h
+  cmFilePathUuid.cxx
   cmFileTimeComparison.cxx
   cmFileTimeComparison.h
   cmFortranLexer.cxx
diff --git a/Source/cmFilePathUuid.cxx b/Source/cmFilePathUuid.cxx
new file mode 100644
index 000..2c8aeec
--- /dev/null
+++ b/Source/cmFilePathUuid.cxx
@@ -0,0 +1,162 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2016 Sebastian Holtermann (sebh...@xwmw.org)
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+*/
+
+#include "cmFilePathUuid.h"
+
+#include "cmCryptoHash.h"
+#include "cmMakefile.h"
+#include "cmSystemTools.h"
+#include "cmsys/Base64.h"
+
+cmFilePathUuid::cmFilePathUuid(cmMakefile* makefile)
+{
+  initParentDirs(makefile->GetCurrentSourceDirectory(),
+ makefile->GetCurrentBinaryDirectory(),
+ makefile->GetHomeDirectory(),
+ makefile->GetHomeOutputDirectory());
+}
+
+cmFilePathUuid::cmFilePathUuid(const std::string& currentSrcDir,
+   const std::string& currentBinDir,
+   const std::string& projectSrcDir,
+   const std::string& projectBinDir)
+{
+  initParentDirs(currentSrcDir, currentBinDir, projectSrcDir, projectBinDir);
+}
+
+void cmFilePathUuid::initParentDirs(const std::string& currentSrcDir,
+const std::string& currentBinDir,
+const std::string& projectSrcDir,
+const std::string& projectBinDir)
+{
+  parentDirs[0].first = cmsys::SystemTools::GetRealPath(currentSrcDir);
+  parentDirs[0].second = "CurrentSource";
+  parentDirs[1].first = cmsys::SystemTools::GetRealPath(currentBinDir);
+  parentDirs[1].second = "CurrentBinary";
+  parentDirs[2].first = cmsys::SystemTools::GetRealPath(projectSrcDir);
+  parentDirs[2].second = "ProjectSource";
+  parentDirs[3].first = cmsys::SystemTools::GetRealPath(projectBinDir);
+  parentDirs[3].second = "ProjectBinary";
+}
+
+std::string cmFilePathUuid::get(const std::string& filePath,
+const char* outputPrefix,
+const char* outputSuffix)
+{
+  std::string sourceFilename = cmsys::SystemTools::GetFilenameName(filePath);
+  std::string sourceBasename =
+cmsys::SystemTools::GetFilenameWithoutLastExtension(sourceFilename);
+
+  // Acquire checksum string
+  std::string checksum;
+  {
+std::string sourceRelPath;
+std::string sourceRelSeed;
+GetRelPathSeed(filePath, sourceRelPath, sourceRelSeed);
+checksum = GetChecksumSt

[cmake-developers] QtAutogen 3.6.0 directory nesting overflow patch

[Sebastian Holtermann]

Hi,

I have updated the patch for CMake 3.6.0 to fix
https://gitlab.kitware.com/cmake/cmake/issues/16209
This patch introduces a new class cmFilePathUuid which
is used in QtAutogen to generated unique filenames.
The name generation algorithm is the same as in
http://public.kitware.com/pipermail/cmake-developers/2016-July/029087.html
but the paths initialization moved to the class constructor
- which also accepts a cmMakefile pointer.

Please review.

-Sebastian

P.S.
I'm just an enthusiastic amateur doing this in my spare time.
Please apologize me if I can't reply immediately.


>From ccdfb4f132ed3a1ddbbff466d885b4f63a178a2e Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann <sebh...@xwmw.org>
Date: Tue, 26 Jul 2016 16:39:12 +0200
Subject: [PATCH] QtAutogen fix for too deep nested directory generation.

Instead of generating moc_* and qrc_* files in subdirectories
that reflect their source's location in the source tree
the files get generated solely in the TARGET_NAME_automoc.dir/
but get a Base64 encoded checksum suffix that was generated
from their source path and a few more seed strings.
---
 Source/CMakeLists.txt   |   1 +
 Source/cmFilePathUuid.cxx   | 162 
 Source/cmFilePathUuid.h |  70 ++
 Source/cmQtAutoGeneratorInitializer.cxx |  76 +++
 Source/cmQtAutoGenerators.cxx   | 123 +++-
 Source/cmQtAutoGenerators.h |   4 +-
 6 files changed, 300 insertions(+), 136 deletions(-)
 create mode 100644 Source/cmFilePathUuid.cxx
 create mode 100644 Source/cmFilePathUuid.h

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 3223831..645542c 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -238,6 +238,7 @@ set(SRCS
   cmFileLockPool.h
   cmFileLockResult.cxx
   cmFileLockResult.h
+  cmFilePathUuid.cxx
   cmFileTimeComparison.cxx
   cmFileTimeComparison.h
   cmFortranLexer.cxx
diff --git a/Source/cmFilePathUuid.cxx b/Source/cmFilePathUuid.cxx
new file mode 100644
index 000..4ca99c7
--- /dev/null
+++ b/Source/cmFilePathUuid.cxx
@@ -0,0 +1,162 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2016 Sebastian Holtermann (sebh...@xwmw.org)
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+*/
+
+#include "cmFilePathUuid.h"
+
+#include "cmCryptoHash.h"
+#include "cmMakefile.h"
+#include "cmSystemTools.h"
+#include "cmsys/Base64.h"
+
+cmFilePathUuid::cmFilePathUuid(cmMakefile* makefile)
+{
+  initParentDirs(makefile->GetCurrentSourceDirectory(),
+ makefile->GetCurrentBinaryDirectory(),
+ makefile->GetHomeDirectory(),
+ makefile->GetHomeOutputDirectory());
+}
+
+cmFilePathUuid::cmFilePathUuid(const std::string& currentSrcDir,
+   const std::string& currentBinDir,
+   const std::string& projectSrcDir,
+   const std::string& projectBinDir)
+{
+  initParentDirs(currentSrcDir, currentBinDir, projectSrcDir, projectBinDir);
+}
+
+void cmFilePathUuid::initParentDirs(const std::string& currentSrcDir,
+const std::string& currentBinDir,
+const std::string& projectSrcDir,
+const std::string& projectBinDir)
+{
+  parentDirs[0].first = cmsys::SystemTools::GetRealPath(currentSrcDir);
+  parentDirs[0].second = "CurrentSource";
+  parentDirs[1].first = currentBinDir;
+  parentDirs[1].second = "CurrentBinary";
+  parentDirs[2].first = projectSrcDir;
+  parentDirs[2].second = "ProjectSource";
+  parentDirs[3].first = projectBinDir;
+  parentDirs[3].second = "ProjectBinary";
+}
+
+std::string cmFilePathUuid::get(const std::string& filePath,
+const char* outputPrefix,
+const char* outputSuffix)
+{
+  std::string sourceFilename = cmsys::SystemTools::GetFilenameName(filePath);
+  std::string sourceBasename =
+cmsys::SystemTools::GetFilenameWithoutLastExtension(sourceFilename);
+
+  // Acquire checksum string
+  std::string checksum;
+  {
+std::string sourceRelPath;
+std::string sourceRelSeed;
+GetRelPathSeed(filePath, sourceRelPath, sourceRelSeed);
+checksum = GetChecksumString(sourceFilename, sourceRelPath, sourceRelSeed);
+  }
+
+  // Compose the file name
+  std::str

Re: [cmake-developers] Autogen subdirectories patches

[Sebastian Holtermann]

Am 27.07.2016 um 19:31 schrieb Ben Boeckel:

On Wed, Jul 27, 2016 at 17:49:40 +0200, Sebastian Holtermann wrote:

Is there an error exit function in CMake?
Or just exit(-1);


Here's an example I found:

this->Makefile->IssueMessage(
  cmake::INTERNAL_ERROR, "fileFound is true but FileFound is empty!");

after that, it is treated as if an error occurred; this loop should
probably be bailed from.


Unfortunately the function is called in two places of which one
does not provide a Makefile (the cmake -E call).

It is very unlikely that an invalid character appears ever
and if it does it is likely that something else is very wrong.
In the patch I sent earlier in this case cmake just drops a note
via std::cerr and calls exit(-1). IMO this is sufficient.

-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] Autogen subdirectories patches

[Sebastian Holtermann]

Am 27.07.2016 um 17:49 schrieb Sebastian Holtermann:



Doing so I found that Base64 allows '+' and '/' as characters which is
bad for directory names obviously.
For now these characters get replaced with 'A' and 'B'.


'_' and '@' would be better replacements (with comments why they are
used) since 'A' and 'B' are already characters in Base64.


Some quick research (aka googling) revealed
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_278

It seems '_' and '-' are safer choices.


+// unexpected hexchar


This raise an internal error, not just be a comment.


Is there an error exit function in CMake?
Or just exit(-1);


+  }
+}
+hashBytes[ii] = hbyte[0] | (hbyte[1] << 4);
+  }
+}
+// Convert hash bytes to Base64 text string
+{
+  std::vector base64Bytes(hashBytes.size() * 2, 0);
+  cmsysBase64_Encode([0], hashBytes.size(),
[0], 0);
+  checksumBase64 = reinterpret_cast([0]);
+  // Base64 allows '+' and '/' characters. Replace these.


This comment should indicate it is because the string is used as part of
a path and that these characters tend to cause problems in paths.


Ok.



The patch.

-Sebastian


>From 30d0c7b61a2ffbc9004cd32a88330078ec8d75a4 Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann <sebh...@xwmw.org>
Date: Tue, 26 Jul 2016 16:39:12 +0200
Subject: [PATCH] QtAutogen fix for too deep nested directory generation.

Instead of generating moc_* and qrc_* files in subdirectories
that reflect their source's location in the source tree
the files get generated solely in the TARGET_NAME_automoc.dir/
but get a Base64 encoded checksum suffix that was generated
from their source path and a few more seed strings.
---
 Source/cmQtAutoGeneratorInitializer.cxx |  79 +++-
 Source/cmQtAutoGenerators.cxx   | 215 +++-
 Source/cmQtAutoGenerators.h |  21 +++-
 3 files changed, 192 insertions(+), 123 deletions(-)

diff --git a/Source/cmQtAutoGeneratorInitializer.cxx b/Source/cmQtAutoGeneratorInitializer.cxx
index dd19760..6bbe29c 100644
--- a/Source/cmQtAutoGeneratorInitializer.cxx
+++ b/Source/cmQtAutoGeneratorInitializer.cxx
@@ -12,6 +12,7 @@
 */
 
 #include "cmQtAutoGeneratorInitializer.h"
+#include "cmQtAutoGenerators.h"
 
 #include "cmLocalGenerator.h"
 #include "cmMakefile.h"
@@ -53,49 +54,24 @@ static std::string GetAutogenTargetBuildDir(cmGeneratorTarget const* target)
   return targetDir;
 }
 
-static std::string GetSourceRelativePath(cmGeneratorTarget const* target,
- const std::string& fileName)
+static std::string GetQrcBuildPath(cmGeneratorTarget const* target,
+   const std::string& qrcSourceName)
 {
-  std::string pathRel;
-  // Test if the file is child to any of the known directories
+  std::string rccOutputPath = GetAutogenTargetBuildDir(target);
+  // Create output directory
+  cmSystemTools::MakeDirectory(rccOutputPath.c_str());
+
+  rccOutputPath += "qrc_";
   {
-const std::string fileNameReal = cmsys::SystemTools::GetRealPath(fileName);
-std::string parentDirectory;
-bool match(false);
-{
-  std::string testDirs[4];
-  {
-cmMakefile* makefile = target->Target->GetMakefile();
-testDirs[0] = makefile->GetCurrentSourceDirectory();
-testDirs[1] = makefile->GetCurrentBinaryDirectory();
-testDirs[2] = makefile->GetHomeDirectory();
-testDirs[3] = makefile->GetHomeOutputDirectory();
-  }
-  for (int ii = 0; ii != sizeof(testDirs) / sizeof(std::string); ++ii) {
-const ::std::string testDir =
-  cmsys::SystemTools::GetRealPath(testDirs[ii]);
-if (!testDir.empty() &&
-cmsys::SystemTools::IsSubDirectory(fileNameReal, testDir)) {
-  parentDirectory = testDir;
-  match = true;
-  break;
-}
-  }
-}
-// Use root as fallback parent directory
-if (!match) {
-  cmsys::SystemTools::SplitPathRootComponent(fileNameReal,
- );
-}
-pathRel = cmsys::SystemTools::RelativePath(
-  parentDirectory, cmsys::SystemTools::GetParentDirectory(fileNameReal));
+cmMakefile* makefile = target->Target->GetMakefile();
+rccOutputPath += cmQtAutoGeneratorUtil::BuildFileBase(
+  qrcSourceName, makefile->GetCurrentSourceDirectory(),
+  makefile->GetCurrentBinaryDirectory(), makefile->GetHomeDirectory(),
+  makefile->GetHomeOutputDirectory());
   }
-  // Sanitize relative path
-  if (!pathRel.empty()) {
-pathRel += '/';
-cmSystemTools::ReplaceString(pathRel, "..", "__");
-  }
-  return pathRel;
+  rccOutputPath += ".cpp";
+
+  return rccOutput

Re: [cmake-developers] Autogen subdirectories patches

[Sebastian Holtermann]

Doing so I found that Base64 allows '+' and '/' as characters which is
bad for directory names obviously.
For now these characters get replaced with 'A' and 'B'.


'_' and '@' would be better replacements (with comments why they are
used) since 'A' and 'B' are already characters in Base64.


Some quick research (aka googling) revealed
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_278
It seems '_' and '-' are safer choices.


+// unexpected hexchar


This raise an internal error, not just be a comment.


Is there an error exit function in CMake?
Or just exit(-1);


+  }
+}
+hashBytes[ii] = hbyte[0] | (hbyte[1] << 4);
+  }
+}
+// Convert hash bytes to Base64 text string
+{
+  std::vector base64Bytes(hashBytes.size() * 2, 0);
+  cmsysBase64_Encode([0], hashBytes.size(), [0], 0);
+  checksumBase64 = reinterpret_cast([0]);
+  // Base64 allows '+' and '/' characters. Replace these.


This comment should indicate it is because the string is used as part of
a path and that these characters tend to cause problems in paths.


Ok.

-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] Autogen subdirectories patches

[Sebastian Holtermann]

Thanks for the feedback.


I have prepared an other approach which uses checksum suffixes
instead of nested directory generation.
This was tested on my Debian/amd64/Makefile setup.


Interesting; I like it. Might be worthwhile to reuse it for the .o files
in the future as well (since these can conflict, but are much less
likely to do so).


Please review.


Could you run clang-format over the code? There are a number of style
issues that it will fix (IIRC, it needs at least Clang 3.8; I'm unsure
what version of the clang that comes with Xcode is sufficient).


I didn't knew clang-format. That's a powerful tool!
I have applied clang-format-3.8 which is available in Debian/Stretch.


+rccOutputPath += cmQtAutoGeneratorUtil::BuildFileBase( qrcSourceName,
+  makefile->GetCurrentSourceDirectory(),
+  makefile->GetCurrentBinaryDirectory(),
+  makefile->GetHomeDirectory(),
+  makefile->GetHomeOutputDirectory() );


Is there a reason we can't pass just the `makefile` down and have it
query all the parameters rather than having 5 arguments?


In fact there is.
cmQtAutoGeneratorUtil::BuildFileBase is shared between
cmQtAutoGeneratorInitializer and cmQtAutoGenerators.
Both hold the directory names in different variables
which is why they must be passed manually.


+  struct TPair {
+const std::string * dir;
+const char * seed;
+  };
+  TPair pDirs[4] = {
+{ , "CurrentSource" },
+{ , "CurrentBinary" },
+{ , "ProjectSource" },
+{ , "ProjectBinary" }
+  };
+  TPair * itc = [0];
+  TPair * ite = [0] + ( sizeof ( pDirs ) / sizeof ( TPair ) );


It might be better to just use a NULL sentinel at the end of the array.
If not, the extra spaces here should go away.


I have changed that to use a NULL sentinel.
std::array would be the best solution IMO but it is not allowed, is it?


+  // Calculate the file ( seed + relative path + name ) checksum
+  std::string checksumBase64;
+  {
+::std::vectorhashBytes;


CMake just uses std::, not ::std::.


Changed.


+{
+  // Acquire hex value hash string
+  std::string hexHash = cmCryptoHash::New("SHA256")->HashString(
+(sourceRelSeed+sourceRelPath+sourceFileName).c_str());
+  // Convert hex value string to bytes
+  hashBytes.resize ( hexHash.size()/2 );
+  for ( unsigned int ii=0; ii != hashBytes.size(); ++ii ) {
+unsigned char byte ( 0 );
+for ( unsigned int jj=0; jj != 2; ++jj ) {
+  unsigned char cval ( 0 );
+  switch ( hexHash[ii*2+jj] ) {
+  case '0': cval=0; break; case '1': cval=1; break;
+  case '2': cval=2; break; case '3': cval=3; break;
+  case '4': cval=4; break; case '5': cval=5; break;
+  case '6': cval=6; break; case '7': cval=7; break;
+  case '8': cval=8; break; case '9': cval=9; break;
+  case 'a': cval=10; break; case 'b': cval=11; break;
+  case 'c': cval=12; break; case 'd': cval=13; break;
+  case 'e': cval=14; break; case 'f': cval=15; break;
+  default: break;


I feel like this is better as:

int nibble = hexHash[ii * 2 + jj];
if ('0' <= nibble && nibble <= '9') {
cval = nibble - '0';
} else if ('a' <= nibble && nibble <= 'f') {
cval = nibble - 'a' + 10;
} else {
// internal error about an unexpected hexchar
}

Alternatively, cmUuid::IntFromHexDigit() (and possibly other methods)
could be refactored to allow this to share an implementation.


I've changed it to the nibble version.
There also was a bit shift error (1 vs 4).
Doing so I found that Base64 allows '+' and '/' as characters which is 
bad for directory names obviously.

For now these characters get replaced with 'A' and 'B'.

If this technique gets wider use using Base58 might be a better choice. 
But it is not available in CMake, yet.


-Sebastian

>From 21c8b1f478c598c244cebab8f6f60956ecc51de0 Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann <sebh...@xwmw.org>
Date: Tue, 26 Jul 2016 16:39:12 +0200
Subject: [PATCH] QtAutogen fix for too deep nested directory generation.

Instead of generating moc_* and qrc_* files in subdirectories
that reflect their source's location in the source tree
the files get generated solely in the TARGET_NAME_automoc.dir/
but get a Base64 encoded checksum suffix that was generated
from their source path and a few more seed strings.
---
 Source/cmQtAutoGeneratorInitializer.cxx |  79 +++-
 Source/cmQtAutoGenerators.cxx   | 211 +++-
 Source/cmQtAutoGenerators.h |  21 +++-
 3 files changed, 188 insertions(+), 123 deletions(-)

diff --git a/Source/cmQtAutoGeneratorInitializer.cxx b/Source/cmQtAutoGeneratorInitializer.cxx
index dd19760..6bbe29c 100644
--- 

Re: [cmake-developers] Autogen subdirectories patches

[Sebastian Holtermann]

Am 21.07.2016 um 17:40 schrieb Brad King:

On 04/22/2016 09:37 AM, Brad King wrote:

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


Unfortunately I've had to revert some of these changes due to
regressions they cause.  See issue here:

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


Hi,
I have prepared an other approach which uses checksum suffixes
instead of nested directory generation.
This was tested on my Debian/amd64/Makefile setup.

-- From the commit:
Subject: [PATCH] QtAutogen fix for too deep nested directory generation.

Instead of generating moc_* and qrc_* files in subdirectories
that reflect their source's location in the source tree
the files get generated solely in the TARGET_NAME_automoc.dir/
but get a Base64 encoded checksum suffix that was generated
from their source path and a few more seed strings.
--

Please review.

-Sebastian

>From 3cdb41e57e45ae145066b18a00aac53c9801b332 Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann <sebh...@xwmw.org>
Date: Tue, 26 Jul 2016 16:39:12 +0200
Subject: [PATCH] QtAutogen fix for too deep nested directory generation.

Instead of generating moc_* and qrc_* files in subdirectories
that reflect their source's location in the source tree
the files get generated solely in the TARGET_NAME_automoc.dir/
but get a Base64 encoded checksum suffix that was generated
from their source path and a few more seed strings.
---
 Source/cmQtAutoGeneratorInitializer.cxx |  80 +++-
 Source/cmQtAutoGenerators.cxx   | 217 +++-
 Source/cmQtAutoGenerators.h |  26 +++-
 3 files changed, 202 insertions(+), 121 deletions(-)

diff --git a/Source/cmQtAutoGeneratorInitializer.cxx b/Source/cmQtAutoGeneratorInitializer.cxx
index dd19760..fcc9367 100644
--- a/Source/cmQtAutoGeneratorInitializer.cxx
+++ b/Source/cmQtAutoGeneratorInitializer.cxx
@@ -12,6 +12,7 @@
 */
 
 #include "cmQtAutoGeneratorInitializer.h"
+#include "cmQtAutoGenerators.h"
 
 #include "cmLocalGenerator.h"
 #include "cmMakefile.h"
@@ -53,49 +54,25 @@ static std::string GetAutogenTargetBuildDir(cmGeneratorTarget const* target)
   return targetDir;
 }
 
-static std::string GetSourceRelativePath(cmGeneratorTarget const* target,
- const std::string& fileName)
+static std::string GetQrcBuildPath(cmGeneratorTarget const* target,
+  const std::string& qrcSourceName)
 {
-  std::string pathRel;
-  // Test if the file is child to any of the known directories
+  std::string rccOutputPath = GetAutogenTargetBuildDir(target);
+  // Create output directory
+  cmSystemTools::MakeDirectory(rccOutputPath.c_str());
+
+  rccOutputPath += "qrc_";
   {
-const std::string fileNameReal = cmsys::SystemTools::GetRealPath(fileName);
-std::string parentDirectory;
-bool match(false);
-{
-  std::string testDirs[4];
-  {
-cmMakefile* makefile = target->Target->GetMakefile();
-testDirs[0] = makefile->GetCurrentSourceDirectory();
-testDirs[1] = makefile->GetCurrentBinaryDirectory();
-testDirs[2] = makefile->GetHomeDirectory();
-testDirs[3] = makefile->GetHomeOutputDirectory();
-  }
-  for (int ii = 0; ii != sizeof(testDirs) / sizeof(std::string); ++ii) {
-const ::std::string testDir =
-  cmsys::SystemTools::GetRealPath(testDirs[ii]);
-if (!testDir.empty() &&
-cmsys::SystemTools::IsSubDirectory(fileNameReal, testDir)) {
-  parentDirectory = testDir;
-  match = true;
-  break;
-}
-  }
-}
-// Use root as fallback parent directory
-if (!match) {
-  cmsys::SystemTools::SplitPathRootComponent(fileNameReal,
- );
-}
-pathRel = cmsys::SystemTools::RelativePath(
-  parentDirectory, cmsys::SystemTools::GetParentDirectory(fileNameReal));
+cmMakefile* makefile = target->Target->GetMakefile();
+rccOutputPath += cmQtAutoGeneratorUtil::BuildFileBase( qrcSourceName,
+  makefile->GetCurrentSourceDirectory(),
+  makefile->GetCurrentBinaryDirectory(),
+  makefile->GetHomeDirectory(),
+  makefile->GetHomeOutputDirectory() );
   }
-  // Sanitize relative path
-  if (!pathRel.empty()) {
-pathRel += '/';
-cmSystemTools::ReplaceString(pathRel, "..", "__");
-  }
-  return pathRel;
+  rccOutputPath += ".cpp";
+
+  return rccOutputPath;
 }
 
 static void SetupSourceFiles(cmGeneratorTarget const* target,
@@ -129,15 +106,7 @@ static void SetupSourceFiles(cmGeneratorTarget const* target,
   if (ext == "qrc" &&
   !cmSystemTools::IsOn(sf->GetPropertyForUser("SKIP_AUTORCC"))) {
 
-std::string rcc_

Re: [cmake-developers] Autogen subdirectories patches

[Sebastian Holtermann]

Am 21.07.2016 um 17:40 schrieb Brad King:

On 04/22/2016 09:37 AM, Brad King wrote:

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


Unfortunately I've had to revert some of these changes due to
regressions they cause.  See issue here:

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



I've seen it.
At the moment I'm busy but I'll try to look at it next week.

-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

[cmake-developers] Autogen message cleanups

[Sebastian Holtermann]

Two more autogen patches with message cleanups/tweaks.

-Sebastian
>From 0c044ee28d3c27c380e7c9bf6ab3978746ed4049 Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann <sebh...@xwmw.org>
Date: Sun, 24 Apr 2016 15:00:26 +0200
Subject: [PATCH 1/2] Autogen: Message cleanups: Compose messages in
 std::stringstream

To avoid Race conditions with other processes writing to stdout/stderr compose
the whole message in a std::stringstream then submit the single complete message.
---
 Source/cmQtAutoGeneratorInitializer.cxx |  12 +-
 Source/cmQtAutoGenerators.cxx   | 262 +++-
 Source/cmQtAutoGenerators.h |   5 +-
 3 files changed, 170 insertions(+), 109 deletions(-)

diff --git a/Source/cmQtAutoGeneratorInitializer.cxx b/Source/cmQtAutoGeneratorInitializer.cxx
index ea9ea7c..f89a235 100644
--- a/Source/cmQtAutoGeneratorInitializer.cxx
+++ b/Source/cmQtAutoGeneratorInitializer.cxx
@@ -592,8 +592,10 @@ static std::string ListQt5RccInputs(cmSourceFile* sf,
 , 0, cmSystemTools::OUTPUT_NONE);
   if (!result || retVal)
 {
-std::cerr << "AUTOGEN: error: Rcc list process for " << sf->GetFullPath()
-  << " failed:\n" << rccStdOut << "\n" << rccStdErr << std::endl;
+std::stringstream msg;
+msg << "AUTOGEN: error: Rcc list process for " << sf->GetFullPath()
+<< " failed:\n" << rccStdOut << "\n" << rccStdErr << std::endl;
+std::cerr << msg.str();
 return std::string();
 }
 
@@ -623,8 +625,10 @@ static std::string ListQt5RccInputs(cmSourceFile* sf,
   std::string::size_type pos = eline.find(searchString);
   if (pos == std::string::npos)
 {
-std::cerr << "AUTOGEN: error: Rcc lists unparsable output "
-  << eline << std::endl;
+std::stringstream msg;
+msg << "AUTOGEN: error: Rcc lists unparsable output "
+<< eline << std::endl;
+std::cerr << msg.str();
 return std::string();
 }
   pos += searchString.length();
diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index 3c6db2d..5345ca4 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -549,7 +549,9 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
 const std::string  = *it;
 if (this->Verbose)
   {
-  std::cout << "AUTOGEN: Checking " << absFilename << std::endl;
+  std::stringstream msg;
+  msg << "AUTOGEN: Checking " << absFilename << std::endl;
+  this->LogInfo(msg.str());
   }
 if (this->RelaxedMode)
   {
@@ -577,7 +579,9 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
   const std::string  = *it;
   if (this->Verbose)
 {
-std::cout << "AUTOGEN: Checking " << absFilename << std::endl;
+std::stringstream msg;
+msg << "AUTOGEN: Checking " << absFilename << std::endl;
+this->LogInfo(msg.str());
 }
   this->ParseForUic(absFilename, includedUis);
   }
@@ -607,17 +611,20 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
 
   if (this->RunMocFailed)
 {
-std::cerr << "moc failed..." << std::endl;
+std::stringstream msg; msg << "moc failed..." << std::endl;
+this->LogError(msg.str());
 return false;
 }
   if (this->RunUicFailed)
 {
-std::cerr << "uic failed..." << std::endl;
+std::stringstream msg; msg << "uic failed..." << std::endl;
+this->LogError(msg.str());
 return false;
 }
   if (this->RunRccFailed)
 {
-std::cerr << "rcc failed..." << std::endl;
+std::stringstream msg; msg << "rcc failed..." << std::endl;
+this->LogError(msg.str());
 return false;
 }
 
@@ -637,8 +644,10 @@ void cmQtAutoGenerators::ParseCppFile(const std::string& absFilename,
   const std::string contentsString = ReadAll(absFilename);
   if (contentsString.empty())
 {
-std::cerr << "AUTOGEN: warning: " << absFilename << ": file is empty\n"
-  << std::endl;
+std::stringstream msg;
+msg << "AUTOGEN: warning: " << absFilename << ": file is empty\n"
+<< std::endl;
+this->LogError(msg.str());
 return;
 }
   this->ParseForUic(absFilename, contentsString, includedUis);
@@ -670,7 +679,6 @@ void cmQtAutoGenerators::ParseCppFile(const std::string& absFilename,
 do
   {
   con

Re: [cmake-developers] Autogen subdirectories patches

[Sebastian Holtermann]

Am 22.04.2016 um 15:37 schrieb 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.


I see. Thanks for the pointer.
Unfortunately I can't spend much more time on this
right now but maybe later.
Thanks again for the kind support.

-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] Autogen subdirectories patches

[Sebastian Holtermann]

Am 19.04.2016 um 19:28 schrieb Brad King:

On 04/19/2016 11:09 AM, Sebastian Holtermann wrote:

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

They introduce
- same name collision checks during moc/qrc/ui generation
- moc/qrc generation in subdirectories to support
sources with the name in different subdirectories
- A test for equally named sources in different subdirectories

Please review.


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.
Thanks and sorry for the wrong indentation btw..


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.

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.

-Sebastian

>From aa246261ba1f98ca245f8c5a93b6c93c7fbe8ec5 Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann <sebh...@xwmw.org>
Date: Thu, 21 Apr 2016 08:44:11 +0200
Subject: [PATCH] Autogen: Generate included moc and ui files in
 TARGET_automoc.dir/

---
 Source/cmQtAutoGenerators.cxx | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index c6ee751..29e2e47 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -564,6 +564,13 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
 this->SearchHeadersForCppFile(absFilename, headerExtensions, headerFiles);
 }
 
+  // Prepend included mocs with build subdirectory
+  for(std::map<std::string, std::string>::iterator
+  it = includedMocs.begin(); it != includedMocs.end(); ++it)
+{
+  it->second = this->TargetBuildSubDir + it->second;
+}
+
   {
   std::vector mocSkipped;
   cmSystemTools::ExpandListArgument(this->SkipMoc, mocSkipped);
@@ -1261,7 +1268,8 @@ bool cmQtAutoGenerators::GenerateUiFiles(
   {
   const std::string & uiFileName = *sit;
   const std::string uiInputFile = sourcePath + uiFileName + ".ui";
-  const std::string uiOutputFile = "ui_" + uiFileName + ".h";
+  const std::string uiOutputFile = this->TargetBuildSubDir
+   + "ui_" + uiFileName + ".h";
   sourceMap[uiInputFile] = uiOutputFile;
   testMap[uiInputFile] = uiOutputFile;
   }
@@ -1321,6 +1329,13 @@ bool cmQtAutoGenerators::GenerateUi(const std::string& realName,
  );
   if (this->GenerateAll || !success || sourceNewerThanUi >= 0)
 {
+// make sure the directory for the resulting ui file exists
+std::string uiDir = uiBuildFile.substr(0, uiBuildFile.rfind('/'));
+if (!cmsys::SystemTools::FileExists(uiDir.c_str(), false))
+  {
+  cmsys::SystemTools::MakeDirectory(uiDir.c_str());
+  }
+
 std::string msg = "Generating ";
 msg += uiOutputFile;
 cmSystemTools::MakefileColorEcho(cmsysTerminal_Color_ForegroundBlue
-- 
2.8.0.rc3

-- 

Powered by www.kitware.com

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

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

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

[Sebastian Holtermann]

Am 19.04.2016 um 19:28 schrieb Brad King:

On 04/19/2016 11:09 AM, Sebastian Holtermann wrote:

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

They introduce
- same name collision checks during moc/qrc/ui generation
- moc/qrc generation in subdirectories to support
sources with the name in different subdirectories
- A test for equally named sources in different subdirectories

Please review.


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.



Ok, thanks.

-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

[cmake-developers] Autogen subdirectories patches

[Sebastian Holtermann]

Hello again,
I've prepared a set of patches that address

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

They introduce
- same name collision checks during moc/qrc/ui generation
- moc/qrc generation in subdirectories to support
  sources with the name in different subdirectories
- A test for equally named sources in different subdirectories

Please review.

-Sebastian


autogen_patches_2016-04-19-1.tar.gz
Description: application/gzip
-- 

Powered by www.kitware.com

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

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

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

[Sebastian Holtermann]

Am 14.04.2016 um 23:06 schrieb Sebastian Holtermann:



These two hunks look like error checks added to the existing logic.
Please split these out into preceding commits with their own messages
explaining the new errors.  Please also include a

  Help/release/dev/automoc-diagnostics.rst

file with a release note explaining the new diagnostics.



Wow, this turned into a git learning session for me.
Git is as awesome as it is hard.

I've split the patch into three as suggested.



Please do not commit.

After checking a greater picture and
https://cmake.org/Bug/view.php?id=16068
I found that an adapted more generic test
would help with qrc and ui file generation, too.
I'm going to start a new thread next week.

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

[Sebastian Holtermann]

These two hunks look like error checks added to the existing logic.
Please split these out into preceding commits with their own messages
explaining the new errors.  Please also include a

  Help/release/dev/automoc-diagnostics.rst

file with a release note explaining the new diagnostics.



Wow, this turned into a git learning session for me.
Git is as awesome as it is hard.

I've split the patch into three as suggested.

-Sebastian

>From 22f5af6aef69adc784287fb20357a98558966443 Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann <sebh...@xwmw.org>
Date: Thu, 14 Apr 2016 18:30:30 +0200
Subject: [PATCH] AUTOMOC: moc file name collision check added.

AUTOMOC searches all source *.cpp files for moc include patterns of the
form #include .  If found the moc_NAME.cpp file will be
generated from the source's header as
${CMAKE_CURRENT_BINARY_DIR}/moc_NAME.cpp.
This allows the compiler to find the moc_NAME.cpp file regardless of the
location of NAME.cpp.
Now two NAME.cpp files in different directories (e.g. a/NAME.cpp, b/NAME.cpp)
would generate the same moc_NAME.cpp file effectively overwriting the other's
one.
A check to identify such name collisions was added.
---
 Help/release/dev/automoc-diagnostics.rst | 13 
 Source/cmQtAutoGenerators.cxx| 35 
 2 files changed, 48 insertions(+)
 create mode 100644 Help/release/dev/automoc-diagnostics.rst

diff --git a/Help/release/dev/automoc-diagnostics.rst b/Help/release/dev/automoc-diagnostics.rst
new file mode 100644
index 000..39a4872
--- /dev/null
+++ b/Help/release/dev/automoc-diagnostics.rst
@@ -0,0 +1,13 @@
+automoc-diagnostics
+--
+
+* AUTOMOC searches all source *.cpp files for moc include patterns of the
+  form #include .  If found the moc_NAME.cpp file will be
+  generated from the source's header as
+  ${CMAKE_CURRENT_BINARY_DIR}/moc_NAME.cpp.
+  This allows the compiler to find the moc_NAME.cpp file regardless of the
+  location of NAME.cpp.
+  Now two NAME.cpp files in different directories (e.g. a/NAME.cpp, b/NAME.cpp)
+  would generate the same moc_NAME.cpp file effectively overwriting the other's
+  one.
+  A check to identify such name collisions was added.
diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index ebe08b0..b2da918 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -99,6 +99,38 @@ static std::string extractSubDir(const std::string& absPath,
   return subDir;
 }
 
+/**
+ * Checks if the same value appears twice in the maps
+ */
+static void nameCollisionTest(
+const std::map<std::string, std::string>& includedMocs,
+const std::map<std::string, std::string>& notIncludedMocs )
+{
+  // Create new merged map
+  std::map<std::string, std::string> mocMap ( includedMocs );
+  mocMap.insert ( notIncludedMocs.begin(), notIncludedMocs.end() );
+
+  // Look for value matches in merged map
+  typedef std::map<std::string, std::string>::const_iterator Iter;
+  for ( Iter ait = mocMap.begin(); ait != mocMap.end(); ++ait )
+{
+for ( Iter bit = ++(Iter ( ait )); bit != mocMap.end(); ++bit )
+  {
+  if ( ait->second == bit->second )
+{
+std::cerr << "AUTOGEN: error: "
+ "The same moc file will be generated "
+ "from different sources." << std::endl
+  << "Rename one of the source files "
+ "to avoid this error." << std::endl
+  << ait->first << " -> " << ait->second << std::endl
+  << bit->first << " -> " << bit->second << std::endl;
+::exit(EXIT_FAILURE);
+}
+  }
+}
+}
+
 cmQtAutoGenerators::cmQtAutoGenerators()
 :Verbose(cmsys::SystemTools::GetEnv("VERBOSE") != 0)
 ,ColorOutput(true)
@@ -589,6 +621,9 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
   std::map<std::string, std::string> notIncludedMocs;
   this->ParseHeaders(headerFiles, includedMocs, notIncludedMocs, includedUis);
 
+  // Lock for moc file name collisions
+  nameCollisionTest ( includedMocs, notIncludedMocs );
+
   // run moc on all the moc's that are #included in source files
   for(std::map<std::string, std::string>::const_iterator
  it = includedMocs.begin();
-- 
2.8.0.rc3

>From 9959dd5c8146a3abde6a463ebc3b7fcf14e64f9c Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann <sebh...@xwmw.org>
Date: Thu, 14 Apr 2016 20:01:04 +0200
Subject: [PATCH] AUTOMOC check for invalid moc file includes starting with ../
 added.

Moc file includes starting with .. would result in moc files beeing
generated in ${CMAKE_CURRENT_BINARY_DIR}/.. which is unsafe.
---
 H

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

[Sebastian Holtermann]

Am 13.04.2016 um 16:40 schrieb Brad King:

On 04/13/2016 10:08 AM, Sebastian Holtermann wrote:

Well, looking into the sources and there is already Tests/QtAutogen.
It covers various #include "moc_..." cases.


Perhaps, but as pointed out in the issue tracker entry I linked those
test cases were not sufficient to fail after the the incorrect fix
made and reverted there.  Please identify why and extend them.


Now after testing it I think the incorrect fix was not incorrect at all.
The feared moc renaming was only applied to mocs that were not #included.

For not #included mocs the (not so) incorrect pach creates long moc 
names in this format: moc_DIRNAME_BASENAME.cpp.


My patch creates the not #included mocs in subdirectories.
This is more robust IMO.

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

[Sebastian Holtermann]

Am 13.04.2016 um 16:40 schrieb Brad King:

On 04/13/2016 10:08 AM, Sebastian Holtermann wrote:

Well, looking into the sources and there is already Tests/QtAutogen.
It covers various #include "moc_..." cases.


Perhaps, but as pointed out in the issue tracker entry I linked those
test cases were not sufficient to fail after the the incorrect fix
made and reverted there.  Please identify why and extend them.



Here is a patch that introduces the same-source-name test
in Tests/QtAutogen.
With the current git cmake the test fails.

The latest moc-directory-patch from earlier in this thread
(cmake_automoc_directory_fix-2016-04-12-3.patch)
fixes the issue.

-Sebastian


>From 3e8b56da1d10defa471bd8fa1f30393c16ad5745 Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann <sebh...@xwmw.org>
Date: Wed, 13 Apr 2016 20:05:04 +0200
Subject: [PATCH] Tests/QtAutogen: New Same source name in different
 directories test

---
 Tests/QtAutogen/CMakeLists.txt | 19 +++
 Tests/QtAutogen/item.cpp   | 10 ++
 Tests/QtAutogen/item.hpp   | 17 +
 Tests/QtAutogen/sname.cpp  | 20 
 Tests/QtAutogen/sname/item.cpp |  6 ++
 Tests/QtAutogen/sname/item.hpp | 13 +
 Tests/QtAutogen/sname/sdA/item.cpp | 10 ++
 Tests/QtAutogen/sname/sdA/item.hpp | 17 +
 Tests/QtAutogen/sname/sdA/sdB/item.cpp | 12 
 Tests/QtAutogen/sname/sdA/sdB/item.hpp | 19 +++
 Tests/QtAutogen/sname/sdB/item.cpp | 10 ++
 Tests/QtAutogen/sname/sdB/item.hpp | 17 +
 Tests/QtAutogen/sname/sdB/sdA/item.cpp | 12 
 Tests/QtAutogen/sname/sdB/sdA/item.hpp | 19 +++
 Tests/QtAutogen/sname/sdC/item.cpp | 13 +
 Tests/QtAutogen/sname/sdC/item.hpp | 17 +
 16 files changed, 231 insertions(+)
 create mode 100644 Tests/QtAutogen/item.cpp
 create mode 100644 Tests/QtAutogen/item.hpp
 create mode 100644 Tests/QtAutogen/sname.cpp
 create mode 100644 Tests/QtAutogen/sname/item.cpp
 create mode 100644 Tests/QtAutogen/sname/item.hpp
 create mode 100644 Tests/QtAutogen/sname/sdA/item.cpp
 create mode 100644 Tests/QtAutogen/sname/sdA/item.hpp
 create mode 100644 Tests/QtAutogen/sname/sdA/sdB/item.cpp
 create mode 100644 Tests/QtAutogen/sname/sdA/sdB/item.hpp
 create mode 100644 Tests/QtAutogen/sname/sdB/item.cpp
 create mode 100644 Tests/QtAutogen/sname/sdB/item.hpp
 create mode 100644 Tests/QtAutogen/sname/sdB/sdA/item.cpp
 create mode 100644 Tests/QtAutogen/sname/sdB/sdA/item.hpp
 create mode 100644 Tests/QtAutogen/sname/sdC/item.cpp
 create mode 100644 Tests/QtAutogen/sname/sdC/item.hpp

diff --git a/Tests/QtAutogen/CMakeLists.txt b/Tests/QtAutogen/CMakeLists.txt
index d5aca55..7aad28b 100644
--- a/Tests/QtAutogen/CMakeLists.txt
+++ b/Tests/QtAutogen/CMakeLists.txt
@@ -110,6 +110,25 @@ set_target_properties(
   AUTOMOC TRUE
 )
 
+# Test AUTOMOC on source files with the same name but in different directories
+add_executable(same_name
+  sname/sdA/sdB/item.cpp
+  sname/sdA/item.cpp
+  sname/sdB/sdA/item.cpp
+  sname/sdB/item.cpp
+  sname/sdC/item.cpp
+  sname/item.cpp
+  item.cpp
+  sname.cpp
+  )
+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
+)
+
 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/item.cpp b/Tests/QtAutogen/item.cpp
new file mode 100644
index 000..0c96f34
--- /dev/null
+++ b/Tests/QtAutogen/item.cpp
@@ -0,0 +1,10 @@
+#include "item.hpp"
+
+namespace root {
+
+void
+Item::go ( )
+{
+}
+
+}
diff --git a/Tests/QtAutogen/item.hpp b/Tests/QtAutogen/item.hpp
new file mode 100644
index 000..bda4bb0
--- /dev/null
+++ b/Tests/QtAutogen/item.hpp
@@ -0,0 +1,17 @@
+#ifndef ROOT_ITEM_HPP
+#define ROOT_ITEM_HPP
+
+#include 
+
+namespace root {
+
+class Item : public QObject
+{
+  Q_OBJECT
+  Q_SLOT
+  void go ( );
+};
+
+}
+
+#endif
diff --git a/Tests/QtAutogen/sname.cpp b/Tests/QtAutogen/sname.cpp
new file mode 100644
index 000..fd125f9
--- /dev/null
+++ b/Tests/QtAutogen/sname.cpp
@@ -0,0 +1,20 @@
+#include "item.hpp"
+#include "sname/item.hpp"
+#include "sname/sdA/item.hpp"
+#include "sname/sdA/sdB/item.hpp"
+#include "sname/sdB/item.hpp"
+#include "sname/sdB/sdA/item.hpp"
+#include "sname/sdC/item.hpp"
+
+int main(int argv, char **args)
+{
+  // Object instances
+  ::root::Item ritem;
+  Item item;
+  ::sdA::Item itemA;
+  ::sdA::sdB::Item itemAB;
+  ::sdB::Item itemB;
+  ::sdB::sdA::Item itemBA;
+  ::sdC::Item itemC;
+  return 0;
+}
diff --git a/Tests/QtAutogen/sname/item.cpp b/Tests/QtAut

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

[Sebastian Holtermann]

Am 13.04.2016 um 16:40 schrieb Brad King:

On 04/13/2016 10:08 AM, Sebastian Holtermann wrote:

Well, looking into the sources and there is already Tests/QtAutogen.
It covers various #include "moc_..." cases.


Perhaps, but as pointed out in the issue tracker entry I linked those
test cases were not sufficient to fail after the the incorrect fix
made and reverted there.  Please identify why and extend them.


Ok, I think I've identifier the problem of the current test
(includer abc.cpp is not in a subdirectory of CMAKE_CURRENT_BINARY_DIR).
I will prepare another test that fails on the incorrect fix, too.

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

[Sebastian Holtermann]

Am 12.04.2016 um 21:26 schrieb 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 for the feedback.

Well, looking into the sources and there is already Tests/QtAutogen.
It covers various #include "moc_..." cases.
What is missing is a same-name case.
I will post an updated patch later.

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

[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 <sebh...@xwmw.org>
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<std::string, std::string> notIncludedMocs;
   this->ParseHeaders(headerFiles, includedMocs, notIncludedMocs, includedUis);
 
+  // Check: Look for name collisions
+{
+typedef std::map<std::string, std::string>::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<std::string, std::string>::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::
-   GetFilenameWithoutLastExte

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

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

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

[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 <sebh...@xwmw.org>
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