Re: [CMake] Cannot get automoc to work properly with recommended Qt5 support method

2016-10-20 Thread Alan W. Irwin 

On 2016-10-20 12:27-0700 Alan W. Irwin wrote:


One especially useful thing I realized from your post is my current
use of a custom_target that depends on MOC_OUT (in your above
nomenclature) is essentially a no-op since MOC_OUT is generated at
CMake time rather then set up as a custom command to be run at build
time.  So there is more cleanup I need to do of my explicit method.


Oops.  That comment is not correct.  If you look at the qt5_wrap_cpp
macro source (in my case in
/usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreMacros.cmake as
packaged by Debian Jessie), it creates a custom command.  So creating
a custom target (like I do in the PLplot build system) that DEPENDS on
MOC_OUT is completely appropriate.  However, that working direct
method is somewhat convoluted so I hope the issue with automoc failing
when the header is in a separate directory is solved in the future.
(See my recent cmake-devel thread where I have given a minimal example
of this sort of automoc failure for the cmake developers to ponder.
That example also has an option to use the direct qt5_wrap_cpp method
with custom target instead of automoc.  That option compiles the
example without problems but the automoc option fails to compile).

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

Re: [CMake] Cannot get automoc to work properly with recommended Qt5 support method

2016-10-20 Thread Alan W. Irwin 

On 2016-10-20 13:48-0500 Steve Lorimer wrote:


Sounds like you have ended up at the same solution I did. I had trouble
getting the automated qt generation working, and in the end I made it
explicit

if(ARG_MOC)
qt5_wrap_cpp(MOC_OUT ${ARG_MOC})
endif()
if(ARG_RES)
qt5_add_resources(RES_OUT ${ARG_RES})
endif()
if(ARG_UI)
qt5_wrap_ui(UI_OUT ${ARG_UI})
endif()

add_library(
${ARG_NAME}
${LINK}
${ARG_SRCS} ${MOC_OUT} ${RES_OUT} ${UI_OUT}
)


Hi Steve:

Thanks for your additional comment.

Yes, I agree explicit is always a good fallback when automatic doesn't
work, but I am hoping the indirect result of this discussion is the
CMake developers will remove the limitations and deficiencies of the
automatic methods supporting Qt5 so they are a lot more useful for
complex real-world software projects.

One especially useful thing I realized from your post is my current
use of a custom_target that depends on MOC_OUT (in your above
nomenclature) is essentially a no-op since MOC_OUT is generated at
CMake time rather then set up as a custom command to be run at build
time.  So there is more cleanup I need to do of my explicit method.

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

Re: [CMake] Cannot get automoc to work properly with recommended Qt5 support method

2016-10-20 Thread Steve Lorimer 
Sounds like you have ended up at the same solution I did. I had trouble
getting the automated qt generation working, and in the end I made it
explicit

if(ARG_MOC)
qt5_wrap_cpp(MOC_OUT ${ARG_MOC})
endif()
if(ARG_RES)
qt5_add_resources(RES_OUT ${ARG_RES})
endif()
if(ARG_UI)
qt5_wrap_ui(UI_OUT ${ARG_UI})
endif()

add_library(
${ARG_NAME}
${LINK}
${ARG_SRCS} ${MOC_OUT} ${RES_OUT} ${UI_OUT}
)


On 20 October 2016 at 12:40, Alan W. Irwin 
wrote:

> Since I have gotten no response to my posts with this subject line, I
> assume automoc really is currently unsuitable for 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.
> I temporarily worked around that issue with symlinks, but I then
> discovered that qt5_wrap_cpp produces exactly the same results as
> automoc (except for the identification of the header in its actual
> location as opposed to the symlink) and with no need for symlinks.  So
> I have abandoned automoc and used a custom target that invokes
> qt5_wrap_cpp instead, and that has allowed me to complete my update to
> the PLplot build system so that it replaces qt5_use_modules calls with
> the modern recommended target_link_libraries method of setting up use
> of Qt5.  And this change has also solved the issue of conflicts
> between plain and keyworded target_link_libraries calls that occurred
> with the qt5_use_modules based method.  So I am now satisfied with the
> PLplot build-system update, but I think automoc would be preferable to
> custom targets involving qt5_wrap_cpp if the above deficiency with
> automoc could be solved, so I will be pursuing that question further
> on the cmake-devel list.
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Cannot get automoc to work properly with recommended Qt5 support method

2016-10-20 Thread Alan W. Irwin 

Since I have gotten no response to my posts with this subject line, I
assume automoc really is currently unsuitable for 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.
I temporarily worked around that issue with symlinks, but I then
discovered that qt5_wrap_cpp produces exactly the same results as
automoc (except for the identification of the header in its actual
location as opposed to the symlink) and with no need for symlinks.  So
I have abandoned automoc and used a custom target that invokes
qt5_wrap_cpp instead, and that has allowed me to complete my update to
the PLplot build system so that it replaces qt5_use_modules calls with
the modern recommended target_link_libraries method of setting up use
of Qt5.  And this change has also solved the issue of conflicts
between plain and keyworded target_link_libraries calls that occurred
with the qt5_use_modules based method.  So I am now satisfied with the
PLplot build-system update, but I think automoc would be preferable to
custom targets involving qt5_wrap_cpp if the above deficiency with
automoc could be solved, so I will be pursuing that question further
on the cmake-devel list.

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

Re: [CMake] Cannot get automoc to work properly with recommended Qt5 support method

2016-10-17 Thread Alan W. Irwin 

On 2016-10-16 18:40-0700 Alan W. Irwin wrote:


To be explicit suppose you have some source code named fooqt.cpp
which contains

#include "barqt.h"

which declares some classes for the software package that refer to Q_OBJECT
and some classes that do not refer to Q_OBJECT.

What is the #include recipe to get automoc to work for this specific case?

In the next few hours I plan to try some #include variations allowed
by the ambiguities of the above documentation so I may eventually
answer my own question by these experiments.  But it would be nice to
get a definitive answer.


It turned out I could get it to work by specifying (at the end of
fooqt.cpp)

#include "moc_barqt.cpp"

However, it only looked in the directory where fooqt.cpp was located
for barqt.h, and a special twist for the PLplot case was barqt.h was
located in a separate directory so it could not find it.  I then tried
adding the appropriate -I directive to CMAKE_AUTOMOC_MOC_OPTIONS.
Note, this time I used the correct name of that variable (and not
AUTOMOC_MOC_OPTIONS like I used before.) So VERBOSE=1 output showed
moc being run properly with all the macros defined as well as that -I
directive.  However, it was run on the barqt.h in the same directory
where fooqt.cpp was located and failed because barqt.h only existed in
a separate directory.  I worked around this by temporarily deploying a
symlink, but that method won't work on Windows, and it may generate
name conflicts for the case of our other Qt5-related components
built in separate directories which also use this same header.

So is there a proper method to work with headers that that are used by
multiple software components in different directories?  If not, I
would consider that to be a big deficiency of the latest Qt5 support
method since this is not a problem for the old Qt5 support method.

By the way, even with the symlink workaround that allows automoc to
generate a moc command that actually works, the moc_barqt.cpp results
that are #included in fooqt.cpp generate two compiler errors when
fooqt.cpp is built.  So I will try to use my rudimentary C++ skills to
debug that issue going forward, and I may ask more questions
concerning those build issues if I cannot figure these build issues
out.

A general comment is this whole project to update to the latest Qt5
support method has been painful, and it is not done yet even for just
the one component I am testing it on so far.  And this pain is despite
the fact that the PLplot build worked smoothly (aside from the
plain/keyword target_link_libraries conflict that motivated this
update) before using the old Qt5 support method.  Less ambiguous
documentation of automoc that included how to deal with include files
that are #included by separate software components in different
directories would ease the pain of using the latest Qt5 support method
considerably.

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

Re: [CMake] Cannot get automoc to work properly with recommended Qt5 support method

2016-10-16 Thread Alan W. Irwin 

On 2016-10-16 13:43-0700 Alan W. Irwin wrote:


Hi Stephen:

I am addressing you directly (as well as the list) because you have
been so helpful with Qt5 issues in the past.

The PLplot build system (some of whose components depend on Qt5)
currently uses one of the older Qt5 support methods documented at
.  But that method is complex
and we are currently running into troubles with it where it uses the
plain target_link_libraries command which conflicts with the keyworded
version that we prefer for our build system.  So I have attempted to
update our Qt5 support to the latest target_link_libraries method
documented at the above URL, but automoc appears not to be working
correctly.

I follow the advice in the above URL and set

set(CMAKE_AUTOMOC ON)

and also set AUTOMOC_MOC_OPTIONS to the following list:

-DPLD_bmpqt;-DPLD_jpgqt;-DPLD_pngqt;-DPLD_ppmqt;-DPLD_tiffqt;-DPLD_svgqt;-DPLD_pdfqt;-DPLD_qtwidget;-DPLD_extqt;-DPLD_memqt

This list is the same as I use for MOC_OPTIONS in the old working method, and
these various macro definitions _must_ be defined to avoid dropping large
swaths of our code from the compilation.  Instead of using

set(CMAKE_INCLUDE_CURRENT_DIR ON)

I use instead (in the directory where the plplotqt library is built)

include_directories(${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ...)

Furthermore, in that same directory I use

target_link_libraries(plplotqt PRIVATE plplot ${MATH_LIB} Qt5::Svg Qt5::Gui 
Qt5::PrintSupport)


for the build.  Although that build apparently works with no obvious
issues, there is no sign of any of the above macros in the
VERBOSE=1 output.  Furthermore, I get the following near-empty result
for the generated bindings/qt_gui/plplotqt_automoc.cpp file which
consists just of the following two lines:

/* This file is autogenerated, do not edit*/
enum some_compilers { need_more_than_nothing };

Finally,

"ldd -r bindings/qt_gui/libplplotqt.st"

shows missing symbols that should be defined if the above macros are
defined.

What am I missing?


I have now looked further, and the missing symbols in the library
correspond exactly to classes in an included header (in a different
PLplot source-tree directory, see below) that have a reference to Q_OBJECT.
Furthermore, when I exclude some of those classes by manipulating
AUTOMOC_MOC_OPTIONS, the corresponding missing symbols disappear from
the library so it appears AUTOMOC_MOC_OPTIONS is actually working
despite no visible sign of that in the "make VERBOSE=1 ..." results.

So I am now looking at something else which is referred to in the
following (from CMake 3.6) automoc documentation (where I have
interpolated questions concerning the ambiguities in that
documentation):

When this property is set ON, CMake will scan the source files at build time 
and invoke moc accordingly.



If an #include statement like #include "moc_foo.cpp" is found,



the
Q_OBJECT class declaration is expected in the header, and moc is run
on the header file. A moc_foo.cpp file will be generated from the
source’s header into the CMAKE_CURRENT_BINARY_DIR directory. This
allows the compiler to find the included moc_foo.cpp file regardless
of the location the original source. []

If an #include statement like #include "foo.moc" is found,



then a
Q_OBJECT is expected in the current source file and moc is run on the
file itself. Additionally, header files with the same base name (like
foo.h) or _p appended to the base name (like foo_p.h) are parsed for
Q_OBJECT macros, and if found, moc is also executed on those files.
AUTOMOC checks multiple header alternative extensions, such as hpp,
hxx etc when searching for headers.



The resulting moc files, which are
not included as shown above in any of the source files are included in
a generated _automoc.cpp file, which is compiled as part
of the target.

I have no such #includes which is probably the entire source of the
issue, but I cannot figure out exactly what to do because of ambiguities
in the above documentation concerning what should be in the header
and what should be in the source file.

To be explicit suppose you have some source code named fooqt.cpp
which contains

#include "barqt.h"

which declares some classes for the software package that refer to Q_OBJECT
and some classes that do not refer to Q_OBJECT.

What is the #include recipe to get automoc to work for this specific case?

In the next few hours I plan to try some #include variations allowed
by the ambiguities of the above documentation so I may eventually
answer my own question by these experiments.  But it would be nice to
get a definitive answer.

@CMake developers: It would be nice to also have an automoc
documentation fix for those ambiguities since the #include pattern in
the source code must be different than what works for older Qt5
support methods that do not use automoc.

Alan

__
Alan W. Irwin

Astronomical research affiliation with Department of Physics

Re: [CMake] Cannot get automoc to work properly with recommended Qt5 support method

2016-10-16 Thread Alan W. Irwin 

On 2016-10-16 13:43-0700 Alan W. Irwin wrote:


To move to a related topic, the above URL has a tutorial example for
the recommended support method which builds the helloworld target from
main.cpp.  It would be nice for Qt5 users to learn from that tutorial
example by building it themselves, but that example is incomplete
since no main.cpp (presumably Qt5-related) is provided (as far as I
can discover).  Any chance you could provide that simple example for
developers like me who don't have a lot of Qt5 or C++ expertise but
who just want to build other's Qt5-related work using the best
CMake-related methods?


Hi Stephen:

Further to this particular subtopic, a google search found me several
qt hello world examples.  The most prominent one does not work (it
uses an ancient method which is no longer supported by Qt!), but
I found that the one in  does work
perfectly with the tutorial Qt5 cmake example.  So I request you
make that hello world routine (or something closely related) available
at  to make that tutorial
more self-contained.

That said, there are no issues with setting macros in this simple
hello world case so it doesn't help with the principal issue covered
in my e-mail where I cannot seem to set the macros needed for automoc
to work properly.

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