Re: [cmake-developers] Current deficiencies of automoc

2016-11-14 Thread 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

Re: [cmake-developers] Current deficiencies of automoc

2016-11-14 Thread 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:

Re: [cmake-developers] Current deficiencies of automoc

2016-11-14 Thread 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

Re: [cmake-developers] Current deficiencies of automoc

2016-11-12 Thread 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.

Re: [cmake-developers] Current deficiencies of automoc

2016-10-24 Thread 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

Re: [cmake-developers] Current deficiencies of automoc

2016-10-22 Thread Alan W. Irwin
On 2016-10-22 07:44+0100 Sascha Cunz wrote: Compilers know exactly where the header files are through include_directories or the equivalent target PROPERTY so why can't automoc find those same header files using similar logic? In short: Because you really do not want automoc to do that. A

Re: [cmake-developers] Current deficiencies of automoc

2016-10-22 Thread 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

Re: [cmake-developers] Current deficiencies of automoc

2016-10-22 Thread Craig Scott
Good background, just a minor correction: On Sat, Oct 22, 2016 at 5:44 PM, Sascha Cunz wrote: > > The problem here is, that once a target is created in CMake, you can’t add > any files to it. So this has to be done that way. > Not actually true, the target_sources()

Re: [cmake-developers] Current deficiencies of automoc

2016-10-22 Thread Sascha Cunz
> Compilers know exactly where the header files are through > include_directories or the equivalent target PROPERTY so why can't > automoc find those same header files using similar logic? In short: Because you really do not want automoc to do that. A bit longer; highlighting the semantic

Re: [cmake-developers] Current deficiencies of automoc

2016-10-21 Thread Alan W. Irwin
On 2016-10-22 03:35+0100 Sascha Cunz wrote: But automoc must know where to look for. It can only do that if something tells it where to look - If your header files are in the same directory as the source files, they’re getting added and scanned automatically. If, like in your example, the

Re: [cmake-developers] Current deficiencies of automoc

2016-10-21 Thread Sascha Cunz
Hi Alan, > On 22 Oct 2016, at 02:01, Alan W. Irwin wrote: > … > I don't agree with your above conclusion. The above remarks immediately > refer to > header files and imply automoc scans them Which it does :) > to find the ones that contain the Q_OBJECT macro and

Re: [cmake-developers] Current deficiencies of automoc

2016-10-21 Thread Alan W. Irwin
On 2016-10-21 23:54+0200 el.bar...@gmx.de wrote: 1. The automoc documentation at only documents the #include method (which doesn't work for the current test case nor for PLplot), and the above working fullpath method is not documented

Re: [cmake-developers] Current deficiencies of automoc

2016-10-21 Thread Nagger
Am 21.10.2016 um 13:39 schrieb Alan W. Irwin: On 2016-10-21 09:42+0200 Sebastian Holtermann wrote: 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

Re: [cmake-developers] Current deficiencies of automoc

2016-10-21 Thread 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

Re: [cmake-developers] Current deficiencies of automoc

2016-10-21 Thread Jean-Michaël Celerier
On Fri, Oct 21, 2016 at 10:10 AM, Sebastian Holtermann wrote: > > A quick fix for the example would be to explicitly add the > headers-to-moc to the sources list. This has the nice side-effect of making your project much easier to use in IDEs. -- Powered by www.kitware.com

Re: [cmake-developers] Current deficiencies of automoc

2016-10-21 Thread 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

Re: [cmake-developers] Current deficiencies of automoc

2016-10-20 Thread 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

Re: [cmake-developers] Current deficiencies of automoc

2016-10-20 Thread 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. A minimal example illustrating the issue is a great idea. However, the

Re: [cmake-developers] Current deficiencies of automoc

2016-10-20 Thread Alan W. Irwin
Disclaimer: I am no expert on any of this stuff so the conclusions I have drawn are based on the particular experiments I have done and are probably limited because of that. On 2016-10-20 21:17+0200 Tobias Hunger wrote: Hi! Am 20.10.2016 21:08 schrieb "Brad King" :

Re: [cmake-developers] Current deficiencies of automoc

2016-10-20 Thread Tobias Hunger
Hi! Am 20.10.2016 21:08 schrieb "Brad King" : > On 10/20/2016 02:30 PM, Alan W. Irwin wrote: > > To be specific here is the way I believe automoc should work. If > > > > #include "moc_.cpp" > > > > is found in a source file under automoc > > control, then if moc_.cpp could

Re: [cmake-developers] Current deficiencies of automoc

2016-10-20 Thread Brad King
On 10/20/2016 02:30 PM, Alan W. Irwin wrote: > The deficiency I found with automoc is (as far as I can tell) it does > not properly handle the case where the header that should be processed > by moc is located in a different source-tree directory than the source > file that includes that header.

[cmake-developers] Current deficiencies of automoc

2016-10-20 Thread Alan W. Irwin
This is a follow up to the CMake mailing list thread with the subject line "Cannot get automoc to work properly with recommended Qt5 support method". The deficiency I found with automoc is (as far as I can tell) it does not properly handle the case where the header that should be processed by