plot-qt does not compile

[Johan Hake]

In the hard coded CMakeList it is tested for DOLFIN_ENABLE_QT and DOLFIN_ENABLE_VTK and both are unset. Should it be tested agains HAS_QT and HAS_VTK instead?

[Joachim Haga (jobh)]

I believe HAS_FOO are defined at preprocessor level, not at cmake level. DOLFIN_ENABLE_FOO should be set if you compile as "make demo_plot-qt" in the tree, but perhaps not if you compile stand-alone? Is that the issue?

It is possible to use FOO_FOUND instead, but that will fail if the libraries are installed, but disabled in the DOLFIN build. I guess that could be resolved by suitable #ifdefs.

[Johan Hake (johan-hake)]

On 11/15/2012 03:17 PM, Joachim Haga wrote:
> I believe HAS_FOO are defined at preprocessor level, not at cmake level.

Yes, but they are stored in the dolfin config cmake file which get
picked up in the local CMakeList file for that demo.

> DOLFIN_ENABLE_FOO should be set if you compile as "make demo_plot-qt" in
> the tree, but perhaps not if you compile stand-alone? Is that the issue?

Yes, that is what I did. I most often never compile all cpp demos from
the build directory. When I do that it do indeed compile the demo.

> It is possible to use FOO_FOUND instead, but that will fail if the
> libraries are installed, but disabled in the DOLFIN build. I guess that
> could be resolved by suitable #ifdefs.

But HAS_FOO does not get defined if ENABLE_FOO is False, so wouldn't it
be better to use the former?

Johan

> ** Changed in: dolfin
> Assignee: (unassigned) => Joachim Haga (jobh)
>

[Joachim Haga (jobh)]

Yes; but HAS_FOO it is not available to cmake, only to the C
preprocessor, so it has to be checked in every .cpp and .h (the latter
because of the moc step) to avoid an ugly compilation failure. I
think.

On 15 November 2012 15:52, Johan Hake <email address hidden> wrote:
> On 11/15/2012 03:17 PM, Joachim Haga wrote:
>> I believe HAS_FOO are defined at preprocessor level, not at cmake level.
>
> Yes, but they are stored in the dolfin config cmake file which get
> picked up in the local CMakeList file for that demo.
>
>> DOLFIN_ENABLE_FOO should be set if you compile as "make demo_plot-qt" in
>> the tree, but perhaps not if you compile stand-alone? Is that the issue?
>
> Yes, that is what I did. I most often never compile all cpp demos from
> the build directory. When I do that it do indeed compile the demo.
>
>> It is possible to use FOO_FOUND instead, but that will fail if the
>> libraries are installed, but disabled in the DOLFIN build. I guess that
>> could be resolved by suitable #ifdefs.
>
> But HAS_FOO does not get defined if ENABLE_FOO is False, so wouldn't it
> be better to use the former?
>
> Johan
>
>> ** Changed in: dolfin
>> Assignee: (unassigned) => Joachim Haga (jobh)
>>
>

[Johan Hake (johan-hake)]

Yes, of course...

ifdefs for a number of HAS_FOOs are used in other demos. Then I guess
you could go back to use the generic CMakeList file?

Johan

On 11/15/2012 04:03 PM, Joachim Berdal Haga wrote:
> Yes; but HAS_FOO it is not available to cmake, only to the C
> preprocessor, so it has to be checked in every .cpp and .h (the latter
> because of the moc step) to avoid an ugly compilation failure. I
> think.
>
> On 15 November 2012 15:52, Johan Hake <email address hidden> wrote:
>> On 11/15/2012 03:17 PM, Joachim Haga wrote:
>>> I believe HAS_FOO are defined at preprocessor level, not at cmake level.
>>
>> Yes, but they are stored in the dolfin config cmake file which get
>> picked up in the local CMakeList file for that demo.
>>
>>> DOLFIN_ENABLE_FOO should be set if you compile as "make demo_plot-qt" in
>>> the tree, but perhaps not if you compile stand-alone? Is that the issue?
>>
>> Yes, that is what I did. I most often never compile all cpp demos from
>> the build directory. When I do that it do indeed compile the demo.
>>
>>> It is possible to use FOO_FOUND instead, but that will fail if the
>>> libraries are installed, but disabled in the DOLFIN build. I guess that
>>> could be resolved by suitable #ifdefs.
>>
>> But HAS_FOO does not get defined if ENABLE_FOO is False, so wouldn't it
>> be better to use the former?
>>
>> Johan
>>
>>> ** Changed in: dolfin
>>> Assignee: (unassigned) => Joachim Haga (jobh)
>>>
>>

[Joachim Haga (jobh)]

No, it still needs to include QT magic for the moc (meta-object compiler) step.

On 15 November 2012 16:04, Johan Hake <email address hidden> wrote:
> Yes, of course...
>
> ifdefs for a number of HAS_FOOs are used in other demos. Then I guess
> you could go back to use the generic CMakeList file?
>
> Johan
>
> On 11/15/2012 04:03 PM, Joachim Berdal Haga wrote:
>> Yes; but HAS_FOO it is not available to cmake, only to the C
>> preprocessor, so it has to be checked in every .cpp and .h (the latter
>> because of the moc step) to avoid an ugly compilation failure. I
>> think.
>>
>> On 15 November 2012 15:52, Johan Hake <email address hidden> wrote:
>>> On 11/15/2012 03:17 PM, Joachim Haga wrote:
>>>> I believe HAS_FOO are defined at preprocessor level, not at cmake level.
>>>
>>> Yes, but they are stored in the dolfin config cmake file which get
>>> picked up in the local CMakeList file for that demo.
>>>
>>>> DOLFIN_ENABLE_FOO should be set if you compile as "make demo_plot-qt" in
>>>> the tree, but perhaps not if you compile stand-alone? Is that the issue?
>>>
>>> Yes, that is what I did. I most often never compile all cpp demos from
>>> the build directory. When I do that it do indeed compile the demo.
>>>
>>>> It is possible to use FOO_FOUND instead, but that will fail if the
>>>> libraries are installed, but disabled in the DOLFIN build. I guess that
>>>> could be resolved by suitable #ifdefs.
>>>
>>> But HAS_FOO does not get defined if ENABLE_FOO is False, so wouldn't it
>>> be better to use the former?
>>>
>>> Johan
>>>
>>>> ** Changed in: dolfin
>>>> Assignee: (unassigned) => Joachim Haga (jobh)
>>>>
>>>
>

[Joachim Haga (jobh)]

I found a way to get to the HAS_FOO defines in cmake, and pushed a fix to ~jobh/dolfin/plot-fix.

Coincidentally, I can also answer the following question in the swig cmakefiles:
"""
# What does this do?
get_directory_property(cmake_defs COMPILE_DEFINITIONS)
"""

Answer: It puts the definitions (like HAS_FOO) for the current directory into the variable cmake_defs, which doesn't seem to be used afterwards. Cmake syntax is a bit odd, methinks.