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.
Related
I am working with the Ruby source which has a configure.in script with the following line AC_CHECK_FUNCS(clock_gettime)
On my system it WILL find such a function and Ruby will go ahead and build a binary that depends on this function. However, this function is non-portable to other operating systems so i would like to tell the ./configure script NOT to use this function even if it does find it.
It would be perfect if i can instruct ./configure not to use this function by a command line option, i heavily prefer not to modify the configure.in script if possible. My question is, how do I do this? I can't seem to find the correct command line option to use.
My question is, how do I do this? I can't seem to find the correct command line option to use.
First, there is good advice in the comments: for best results, build on the oldest system you can find (or set up) and try to reduce the dependencies as much as possible. glibc is good about symbol versioning and compatibility, but many other libraries are not.
That said, if you really want to circumvent a check, the way to do it is to pre-populate a cache file with the results you want. One simple way to make the cache is to run configure, then edit it, then re-run configure.
The cache variable naming scheme is documented, but normally you can find what you want by just searching for the function name in config.cache.
Maybe it's even possible to set the cache variable on the configure command line -- but I have never tried this.
When I use clearmake -C gnu on makefiles that use the MAKEFILE_LIST variable, MAKEFILE_LIST is empty. But when I use regular GNU make on the same makefiles, MAKEFILE_LIST is a list of file paths and names (as it should be).
To see what MAKEFILE_LIST is equal to, I'm using $(info $$MAKEFILE_LIST is [${MAKEFILE_LIST}]). There are no spaces in any of the file names, so I know that's not causing any problems, and the ClearCase manual lists some features of GNU make that clearmake does not support, but MAKEFILE_LIST is not among those features.
Has anyone else experienced a similar problem with clearmake and MAKEFILE_LIST? If so, were you able to fix it and how?
Had to look up the MAKEFILE_LIST macro to see what it did. And yes, this isn't something that clearmake currently supports. It's also not something listed as explicitly not supported.
I used the sample make snippet at https://www.gnu.org/software/make/manual/html_node/Special-Variables.html to confirm the lack.
I can't categorize this as a defect, so the best bet would be to avoid the middleman and enter the RFE in the Developerworks RFE community at https://www.ibm.com/developerworks/rfe/
If at all possible, can you please provide a "business justification" in Manager-Speak (Dollars lost/Man hours needed to work around not having the capability)? Like every other non-startup development shop, developer time is at a premium, so it's important to put the impact in.
I can't say that you'll get the answer you want, but you should get a response.
From what you've written looks pretty clear that it's not supported; just because it's not listed in the manual doesn't mean that they support it. That manual might have just not been updated. However, MAKEFILE_LIST was added in GNU make 3.80 which was released in 2002. Pretty lame if they don't indeed support it.
For the amount of $$ you're paying for ClearCase, I would recommend you contact their support and ask them directly rather than trying to get answers from StackOverflow :).
In any event if you want answers from people who use ClearCase I suggest you add that, or at the very least clearmake, to your list of tags.
As illustrated in "Rational ClearCase: clearmake -C gnu and GNUmake diferences.", clearmake is not gmake.
And this thread makes it clear that "base ClearCase" isn't exactly actively developed (though it is still very much maintained with ClearCase 9.x, as shown in this recent clearmake output format).
MAKEFILE_LIST is not mentioned in "env_ccase" (which includes standard UNIX and Linux EVs that are particularly important for ClearCase and MultiSite), and I never had the occasion of using it.
I'm trying to use ccache to speed up my rebuilds and I noticed this in the log:
[2015-04-17T10:41:45.845545 27682] Compiler option -M is unsupported
[2015-04-17T10:41:45.845584 27682] Failed; falling back to running the real compiler
In my experience you need something like the -M flag in order to have make or its equivalent trigger rebuilds correctly. It seems weird that ccache would be tripped up by an option that must be in almost every project's build. Am I missing something? Is there a more preferred option?
This is w/ ccache-3.2.1.
Edit: I tried with -MM as well, no luck.
It is correct that ccache currently doesn't support the compiler options -M and -MM (and it never has supported them).
Some reasons for why the options in question are unupported:
The options tell the compiler to let the preprocessor output make rules instead of the preprocessed source code. This is not a good match for how ccache works; it needs to get hold of the "real" preprocessed output for each compiler invocation (see https://ccache.dev/manual/3.7.11.html#_how_ccache_works).
Nobody has implemented support for the mentioned options, simply put.
It would most likely be possible to implement support by letting ccache run the compiler command twice: one without -M/-MM to retrieve the preprocessed source code (with which the result should be associated) and one with -M/-MM to retrieve the result (make rules).
However, I (speaking as the ccache maintainer for the last six years) have not heard anybody missing support for -M/-MM until now, so my impression is that -M/-MM actually aren't used much.
Am I missing something? Is there a more preferred option?
Yes, I would say that the standard way is to use -MD/-MMD (which are supported by ccache) instead of -M/-MM. -MD/-MMD are superior because they produce both the .o and the .d file in one go, whereas -M/-MM only produce the .d file, so the compiler must in that case be invoked twice by the Makefile for each source code file. See for instance http://www.microhowto.info/howto/automatically_generate_makefile_dependencies.html for how to use -MD/-MMD.
the compilation options are vendor specific (in my knowledge)
so, in makefile, I have to provide,
if FC=ifort
FFLAGS=<long list of options provided by intel>
else
if FC=gfortran
FFLAGS=<same list in gnu way>
end if
is there a way to specify a generic option? by generic, I mean, a vendor
independent way of specifying the options. I don't mind creating them
using autotools(i.e. autoconf, automake). but is there a way?
I am not sure, if this answers your question or provides you any help at all. But, what I use to allow activation of compiler options in a more generic way, is to define variables for specific features, for example warning, debugging, optimization and profiling, and set these according to the compiler currently used.
I am using waf for configuration and building, see for example this build script, where the FCFLAGS are set according to the configured compiler, with different options activated for the various build variants, that are available. I guess, you can do something similar with autotools, or pure make.
I find it difficult sometimes to locate errors/warnings in large projects upon make-ing (gnu). How do I segregate the errors/warnings from the usual compilation messages when the error does not stop the build process from going any further? A wrapper shell script could pick and display whatever I want, but before fleshing out one I thought of asking about the alternatives.
Thanks.
In theory, make -s will suppress the "routine" output of the build process, leaving you with only the errors and warnings. Also in theory, make will stop as soon as it encounters an error.
If either of those is not true for the project(s) you're working with, that's probably due to poorly written makefiles. So fixing the makefiles is one alternative.
To help make sense of verbose builds, some simple highlighting as provided by colorgcc can go a long way. IDEs like eclipse or even emacs can also helpfully pick out the error messages in the build output.
Also, it might be helpful to note that warning and error messages are usually written to stderr, while everything else goes to stdout. So it might be useful to simply discard stdout like so: make >/dev/null.