discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] possible bug in gr_modtool


From: Michael Dickens
Subject: Re: [Discuss-gnuradio] possible bug in gr_modtool
Date: Tue, 14 Jul 2015 10:11:02 -0400

Hi Federico - Yes, that does seem like a bug. Looking at the top-level
docs/doxygen/CMakeLists.txt, this command is:
{{{
add_custom_command(
    OUTPUT ${BUILT_DIRS}
    COMMAND ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile
    WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
    DEPENDS ${GENERATED_DEPS}
    COMMENT "Generating documentation with doxygen"
)
}}}
which contains the DEPENDS. I'm not familiar enough with the doxygen
side of the build system to know what the right thing to do here is, but
adding a dependency on a directory does make sense if there's no
specific input files known within CMake at this time that could be used
instead.

That said, I think the idea here is that if any of the docs files is
changed then you want the docs to be rebuilt ... so, this command should
really depend in inputs files and/or input directories, not the
generated output directory ... yes?

Maybe another GR dev knows more about this part of the build system? -
MLD

On Tue, Jul 14, 2015, at 09:46 AM, Federico Larroca wrote:
> We have been working with our gr-isdbt OOT for some months now, and
> we've stumbled upon what we believe is a small bug in gr_modtool:
> doxygen documentation of the OOT is not updated when doing "make &&
> sudo make install".
>
> After some exploration, we believe the problem is that the
> CMakeLists.txt in docs/doxygen/ has a add_custom_command without a
> DEPENDS declaration. We've patched it by replacing those lines with
> (bold indicates the addition):
>
> add_custom_command(    OUTPUT ${BUILT_DIRS}    COMMAND
> ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile
> WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} *DEPENDS
> ${CMAKE_CURRENT_BINARY_DIR}*    COMMENT "Generating documentation with
> doxygen" )
>
> However, our expertise with cmake is null, so we're not sure this is
> the right solution. Maybe someone in the developement team has the
> "correct" solution. best regards,



reply via email to

[Prev in Thread] Current Thread [Next in Thread]