How do I parse a Makefile in Doxygen . My dir contains *.c and *.h files which it parses correctly. But I am not sure how I can get it to parse Makefile correctly. Is there a special plugin for GNU makefile parsing that I can use.
I could not not file any info on this.
Thanks for help in advance.
I would find it extremely useful if DoxyGen could parse a makefile.
The makefile is central to the build process and would be a very good place to
include an introduction to appear on the main page.
I tried to include it by calling it Makefile.mk and asking doxygen to include the .mk
extension in the input files list.
One of the difficulties which I would foresee is that the comments start with #,
and, as far as I know, there is no multi-line comment block available for make.
I guess this would mean that a revision to doxygen would be needed to support this operation.
I pretty sure that this would be a really useful enhancement to DoxyGen which many people would find useful.
One thing i came across for shell scripts which also does not supported by doxygen. here is the solution link. But even for Makefile/Dockerfile which does not have any real extensions for doxygen to parse. I would recommended to have some unified solution with doxygen.
Related
GCC allows for having command-line options passed by a file by #file syntax. Using this the file should be added as prerequisite (aka dependency) to the target.
I'm not finding any reference in CMake docs about argument files, suggesting it's not supported. Or perhaps just takes a little bit more plumbing, e.g. cat file|xargs? Or some way telling CMake explicitly that the file is a prerequisite? I mean "Prerequisite" according to GNU Make terminology. If file contents change I have to rebuild. AKA dependency.
Which is it? And how does it work?
You should just be able to use target_compile_options() or CXX_<LANG>_FLAGS like you normally would.
Since the flags available for different compilers are usually different, you probably will have one for each compiler you support, in which case you can wrap your target_compile_options() calls with if() blocks based on CMAKE_CXX_COMPILER_ID or the MSVC variable, or use the CXX_COMPILER_ID or X_COMPILER_ID generator expressions to use the right file (if you have multiple files for multiple compilers) for the right compiler.
However, I've also noticed before when trying this that using file flags like this doesn't automatically add the file as a dependency to the target (the CMake won't add a rule for the target to rebuild if that file changes), so you might need to do that manually like this:
# wrap this in a function taking `target` as an argument.
get_target_property(sources ${target} SOURCES)
set_property(SOURCE ${sources}
# DIRECTORY "${PROJECT_SOURCE_DIR}" "${PROJECT_BINARY_DIR}"
TARGET_DIRECTORY ${target}
APPEND PROPERTY OBJECT_DEPENDS "${PROJECT_SOURCE_DIR}/path/to/flags/file.txt"
)
The above snippet courtesy of a user in this GitHub issue. It uses the OBJECT_DEPENDS source file property to make every source file of a target depend on the compiler options file. I (and the author of that code snippet) would classify it as a workaround, since it only works for Generators that support OBJECT_DEPENDS. From the CMake docs:
Specifies a semicolon-separated list of full-paths to files on which any object files compiled from this source file depend. On Makefile Generators and the Ninja generator an object file will be recompiled if any of the named files is newer than it. Visual Studio Generators and the Xcode generator cannot implement such compilation dependencies.
I'm not sure at what level of the toolchain it would be best to request that such automatic dependency-tracking functionality be added. According some of the Ninja buildsystem maintainers in the above linked GitHub issue, (if my noob brain is understanding the words they're saying correctly :P), it's something that could be handled by compilers when they generate depfiles given a compile comand for a source file. I'm currently too scared to ask compiler maintainers if that's the case. If you're interested in digging onto the part that CMake plays in orchestrating other tools to get dependency tracking for things like header files and the creation of dependency-tracking files ("depfiles"), you can go to your CMake installation's Modules folder and grep for CMAKE_DEPFILE_FLAGS_. Then use "find in files" at https://github.dev/Kitware/CMake.
Notes: Visual Studio / MSVC's compiler calls these "command files", gcc doesn't seem to have a particular name for them, and clang calls these "configuration files". They all support similar #file syntax. I'm not sure what the history is with that, but many compilers aim to have levels of compatibility (similar interface to) with GCC.
That's all. If you're bored and want to read a bit about how CMake does header dependency detection (which is loosely related here on the topic of depfiles), see this other post of mine.
Does anyone have an example of how to set up a custom build rule in Xcode that takes a file in a source directory and produces an output in the same folder? I am confused about the three separate areas, one is clearly the command line instruction, but I'm unclear on the rest of the setup. Apple's documentation is... ummm, "limited". I think this would be easy if you could simply see what their internal rule does, but these rules do not display the same screen so it's not easy to figure out what goes where.
The specific problem I'm trying to solve is building a yacc source file. When you build one, yacc (or in this case, the largely compatible bison) produces a .h with defines that you then #include into your C code. Modern dialects will normally build a file into the same directory with the same name as the input - in my case, the parse.y produces a parse.h.
Unfortunately, Apple has defined $(YACC) to include the -Y flag, so instead of building parse.h in the source folder it builds y.tab.h in the DerivedSources folder. I'm trying to override this behaviour without having to change $(YACC).
I always used ctags -nR to generate ctags and believed that this should be sufficient. But I now find that its struggling with C++ code where there are too many matches. Does it need more options to be sent in the command line to make it efficient.
I find eclipse to be a bit better although I believe it needs location of headers etc to be specified for existing projects with Makefile.
ctags -nR
Is this any different from exuberant ctags or is it just an improvement.
Request to not reject or close this question as a non programming question because I am sure programmers use such tools extensively and people in S.O would be the right audience to be able to answer this for they would have used it too as Linux programmers.
I'd struggled with this as well.
The problem here is certainly the C++ part.
ctags does not support it that well and many times it finds string matches instead of global definitions. What really worked for me was to replace standard/exuberant ctags with universal-ctags. C/C++ support has been polished a lot. It does work with additional languages by default. I've been using it mainly for Go and C and it does work like a charm.
Here is the link:
https://github.com/universal-ctags/ctags
If you have your ctags environment set up, probably you only need to run the standard configure/make/make install and you're good to go!
Is it possible to include other type of file in the search result(e.g find the value of CFLAG in the makefile)? Thanks.
Cscope is an excellent tool, but it really only understands C. (And boy, I wish it understood more C; I can't tell you how often I wished I could use Cscope to find a definition of a structure.)
Exuberant Ctags, on the other hand, understands a lot of languages (42 by my ctags --list-languages), one of which is Make.
Run ctags -R . to build a tags database of your source. (ctags has many command line options to configure how it works but this simple invocation works for me in a variety of projects.) Then you can run vim -t CFLAGS to jump right to the definition of CFLAGS in the Makfile. (It also enables the simple ctrl+] lookup in vim -- see vim's :help CTRL-] for details.)
I usually use cscope, ctags, and gid all together in my own source navigating -- each tool does different enough things that most of my needs can be met with one of them -- the trick is figuring out which task is best suited to which tool.
There is a ruby gem that is cscope-like but supports ruby and golang. It is also extensible, so other languages can be added relatively easily.
http://rubygems.org/gems/starscope
I have a large legacy codebase with very complicated makefiles, with lots of variables. Sometimes I need to change them, and I find that it's very difficult to figure out why the change isn't working the way I expect. What I'd like to find is a tool that basically does step-through-debugging of the "make" process, where I would give it a directory, and I would be able to see the value of different variables at different points in the process. None of the debug flags to make seem to show me what I want, although it's possible that I'm missing something. Does anyone know of a way to do this?
Have you been looking at the output from running make -n and make -np, and the biggie make -nd?
Are you using a fairly recent version of gmake?
Have you looked at the free chapter on Debugging Makefiles available on O'Reilly's site for their excellent book "Managing Projects with GNU Make" (Amazon Link).
I'm sure that remake is what you are looking for.
From the homepage:
remake is a patched and modernized version of GNU make utility that adds improved error reporting, the ability to trace execution in a comprehensible way, and a debugger.
It has gdb-like interface and is supported by mdb-mode in (x)emacs which means breakponts, watches etc. And there's DDD if you don't like (x)emacs
From the man page on make command-line options:
-n, --just-print, --dry-run, --recon
Print the commands that would be executed, but do not execute them.
-d Print debugging information in addition to normal processing.
The debugging information says
which files are being considered for remaking,
which file-times are being compared and with what results,
which files actually need to be remade,
which implicit rules are considered and which are applied---
everything interesting about how make decides what to do.
--debug[=FLAGS] Print debugging information in addition to normal processing.
If the FLAGS are omitted, then the behaviour is the same as if -d was specified.
FLAGS may be:
'a' for all debugging output same as using -d,
'b' for basic debugging,
'v' for more verbose basic debugging,
'i' for showing implicit rules,
'j' for details on invocation of commands, and
'm' for debugging while remaking makefiles.
I'm not aware of any specific flag that does exactly what you want, but --print-data-base sounds like it might be useful.
remake --debugger all
More info https://vimeo.com/97397484
https://github.com/rocky/remake/wiki/Installing
There is a GNU make debugger project at http://gmd.sf.net which looks quite useful. The main feature supported by gmd is breakpointing, which may be more useful than stepping. To use this, you download gmd from http://gmd.sf.net and gmsl from http://gmsl.sf.net, and do an 'include gmd' in your makefile.