Re: [cmake-developers] Current deficiencies of automoc
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
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
test_qt5.tar.gz
Description: compressed tarball containing a minimal example of automoc compile failure
--
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] Android Support
On 10/20/2016 04:19 PM, Robert Dailey wrote: > Another question: Will CMake's android support only work with official > NDK releases? Or can I expect it to function with unofficial NDKs such > as Crystax? We assume the official NDK layout. If an unofficial NDK has the same layout it may work. Otherwise additional work may be needed. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Current deficiencies of automoc
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 problem is I am not much of an expert on C++ or Qt5 so reducing the PLplot Qt5 example source code to such a minimal example is going to be somewhat time consuming for me. So unless someone here lends me a hand by implementing the needed simple Qt5 source code, I first plan to look through the many Qt5 demos accessible on the web to see if any of them qualify in terms of no Q_OBJECT in source, but Q_OBJECT in #included header, and as a last resort I will attempt to simplify the PLplot Qt5 example source code. Then follow up with implementing the CMake aspects of that simple example which should be trivial for me. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Android Support
On Thu, Oct 20, 2016 at 2:51 PM, Brad King wrote:
> On 10/20/2016 03:35 PM, Robert Dailey wrote:
>> So using takanome's cmake toolchain, he had support for native app
>> glue. Does CMake offer support for this now? I was able to generate
>> but I'm not able to load in native app glue from the NDK.
>
> We don't currently offer a first-class interface for it but the locations
> are available relative to CMAKE_ANDROID_NDK:
>
> ```
> include_directories("${CMAKE_ANDROID_NDK}/sources/android/native_app_glue")
> set(my_sources ...
>
> ${CMAKE_ANDROID_NDK}/sources/android/native_app_glue/android_native_app_glue.c
> )
> ```
>
> Similarly for cpufeatures and ndk_helper.
>
> That is why
>
>
> https://github.com/taka-no-me/android-cmake/blob/master/AndroidNdkModules.cmake
>
> simply wraps around hard-coded locations.
Thanks a bunch Brad. I simply modified AndroidNdkModules.cmake to use
CMAKE_ANDROID_NDK and it works perfect now.
Another question: Will CMake's android support only work with official
NDK releases? Or can I expect it to function with unofficial NDKs such
as Crystax?
--
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
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" : 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 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 . [snip] this is a plea to the CMake developers to fix the above deficiency If you include moc_name.cpp, then you need to run moc on this *source* file. That is what allows you to have private classes in your source file that derive from QObject. That is not the case I am concerned with which is the source file has no direct reference to the Q_OBJECT macro. Instead it #includes a header that uses that macro. My experiments (see disclaimer above) with that case show moc needs to be run directly on the header, and the resulting generated file needs to be #included in the source file. The headers should be covered by automoc automatically: Any header containing a Q_OBJECT macro should be moc-ed. So there should not be any need to include moc_*.cpp files in source files for any header. Actually my experiments show the headers using the Q_OBJECT macro are completely ignored by automoc unless you specifically put #include moc_.cpp in the source file, and that works only if .h is in the current directory. And I want to see that severe current directory limitation removed as above. At least that is how I always use this with qmake, but I am hardly an expert on how moc should work:-) That lack of expertise goes double for me. :-) See disclaimer above. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Android Support
On 10/20/2016 03:35 PM, Robert Dailey wrote:
> So using takanome's cmake toolchain, he had support for native app
> glue. Does CMake offer support for this now? I was able to generate
> but I'm not able to load in native app glue from the NDK.
We don't currently offer a first-class interface for it but the locations
are available relative to CMAKE_ANDROID_NDK:
```
include_directories("${CMAKE_ANDROID_NDK}/sources/android/native_app_glue")
set(my_sources ...
${CMAKE_ANDROID_NDK}/sources/android/native_app_glue/android_native_app_glue.c
)
```
Similarly for cpufeatures and ndk_helper.
That is why
https://github.com/taka-no-me/android-cmake/blob/master/AndroidNdkModules.cmake
simply wraps around hard-coded locations.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Android Support
So using takanome's cmake toolchain, he had support for native app glue. Does CMake offer support for this now? I was able to generate but I'm not able to load in native app glue from the NDK. On Tue, Oct 18, 2016 at 10:05 AM, Mikhail Filimonov wrote: > Hi Brad, > It looks that those commits broke CMake scripts used to generate Nsight Tegra > projects: > https://gitlab.kitware.com/cmake/cmake/issues/16371 > Even CMake/tree/master/Tests/VSNsightTegra doesn't work with CMake ToT > > Regards, > Mikhail Filimonov > > -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf > Of Brad King > Sent: Friday, August 12, 2016 6:13 PM > To: cmake-developers@cmake.org > Subject: [cmake-developers] Android Support > > Hi Folks, > > I've implemented native support for cross-compiling to Android with CMake > using either an Android NDK or an Android Standalone Toolchain. > I plan to include this in the CMake 3.7 release. > > Please see the MR here: > > https://gitlab.kitware.com/cmake/cmake/merge_requests/62 > > This enables building with simple toolchain files, or even without one: > > $ cmake ../src -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_NDK=/path/to/ndk > > Note that interface compatibility with popular third-party Android toolchain > files is a non-goal of this work (though we should not break them too much). > Instead I'd like to make the support feel native within CMake. For example, > the Android API level is naturally specified by CMAKE_SYSTEM_VERSION. > > If you're interested in this support please fetch the MR branch and try it > out. The Help/manual/cmake-toolchains.7.rst manual has been updated with > documentation about how to use this. > > -Brad > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > --- > This email message is for the sole use of the intended recipient(s) and may > contain > confidential information. Any unauthorized review, use, disclosure or > distribution > is prohibited. If you are not the intended recipient, please contact the > sender by > reply email and destroy all copies of the original message. > --- > -- > > 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 -- 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
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 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 . > [snip] > > this is a plea to the CMake developers to fix the above deficiency If you include moc_name.cpp, then you need to run moc on this *source* file. That is what allows you to have private classes in your source file that derive from QObject. The headers should be covered by automoc automatically: Any header containing a Q_OBJECT macro should be moc-ed. So there should not be any need to include moc_*.cpp files in source files for any header. At least that is how I always use this with qmake, but I am hardly an expert on how moc should work:-) Best Regards, Tobias -- 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
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. [snip] > 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 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 . [snip] > this is a plea to the CMake developers to fix the above deficiency Adding to Cc some folks that may have worked on automoc features in the past. I have little understanding of the feature myself. Unless someone steps forward to implement this it is unlikely to be fixed. > I hate to lose issues that can be trivially fixed on bug trackers, but > if the above automoc fix and automoc documentation fix are not > trivial, then I would be willing to incorporate the above and any > further discussion here into an official CMake bug report. 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. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Current deficiencies of automoc
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 moc is located in a different source-tree directory than the source file that includes that header. For PLplot I have worked around this deficiency by abandoning use of automoc altogether and instead used custom targets that invoked qt5_wrap_cpp. But the whole concept of automoc is far superior to a custom target approach so this is a plea to the CMake developers to fix the above deficiency in automoc. 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 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. My experiments showed that automoc currently falls short of this behaviour and only works if .h is in the current source directory and I consider this deficiency to be a serious bug in automoc. Furthermore, the documentation of automoc needs improving to explicitly name the header file being processed by moc when encountering the above #include. Furthermore, the directories searched for that header file should be stated. For the current buggy state of automoc that would just be the current source tree, but once the bug was fixed it would be everything mentioned in include_directories and their source-tree equivalents. I hate to lose issues that can be trivially fixed on bug trackers, but if the above automoc fix and automoc documentation fix are not trivial, then I would be willing to incorporate the above and any further discussion here into an official CMake bug report. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
