Assume a trivial configure.ac:
AC_INIT([foobar], 1.0)
m4_define([foobar_m4], [foobar.m4])
m4_include(foobar_m4)
with a trivial foobar.m4:
AS_ECHO(["foobar.m4 was included"])
Running autoreconf produces:
aclocal: error: configure.ac:10: file 'foobar_m4' does not exist
autoreconf-2.69: aclocal failed with exit status: 1
How to include m4-expanded filenames in a configure.ac?
The culprit is the aclocal utility, not m4. The m4 expansion works just fine, but before m4 is invoked, aclocal scans configure.ac for dependencies, and it blindly handles the m4_include macro as if it were always called with a literal file argument.
There are two workarounds:
Use the built-in macro include:
m4_builtin([include], foobar_m4)
This will completely circumvent the autoconf-provided m4_include macro, which protects against repeated inclusions of the same file.
Define your own macro that invokes m4_include:
m4_define([my_include], [m4_include][([$1])])dnl
my_include(foobar_m4)
Why the weird quoting? We have to quote m4_include in the above definition so that it is not expanded during the definition of my_include, but quoting the whole m4_include([$1]) invocation would still trip aclocal in the same way as in the question.
As far as I know, there is no built-in way to prevent aclocal from specially treating the m4_include macro. This behavior of aclocal is essential for dependency tracking, so including files in this way is likely to fail due to undefined macros used in included files (this is also explained here).
Related
I modified the readelf.c file in binutils-2.36.1/binutils/ such that it prints a few details differently with some flags such as "s","S","a" and doesn't affect the output of other flags.
I'm trying to test whether the changes I made to the file affected any other flags than the ones I intended(mentinoed above).
and therefore I generated a few tests of the following format :
./binutils/readelf -g ./readelfTests/Objects/ObjectFiles/object_1.o
./binutils/readelf -n ./readelfTests/Objects/ObjectFiles/object_1.o
./binutils/readelf -e ./readelfTests/Objects/ObjectFiles/object_1.o
./binutils/readelf -S ./readelfTests/Objects/ObjectFiles/object_1.o
and so on, you get the point.
the problem is the .o files I have are very basic with few sections and variables therefore running a test on them may not catch the errors in my code, I'd appreciate a way to get some .o files with a lot of sections and variables such that running tests on them may actually be effective.
or alternatively I'd appreciate a way to test my modified readelf file in an automatic way.
I'm trying to port linux kernel's kconfig util to my product
while compiling I got next error:
make[6]: *** No rule to make target `zconf.tab.c', needed by `zconf.tab.o'. Stop.
I found next rule in Makefile.lib for this file
$(obj)/%: $(src)/%_shipped
$(call cmd,shipped)
It looks ok for me and it just works in kernel but not in my product.
Then I added another rule right after previous one.
$(obj)/%c: $(src)/%c_shipped
$(call cmd,shipped)
And now it works just fine.
Can someone explain me what's wrong with original rule?
In my case obj=. and src=. (both = dot). Current dir contains appropriate *_shipped file.
My guess is that $(obj)/%: $(src)/%_shipped qualifies as a match-anything pattern rule. (The manual doesn't mention how targets and prerequisites with with directory components are handled, but it would make sense.)
Note the following in the manual:
A non-terminal match-anything rule cannot apply to a file name that indicates a specific type of data. A file name indicates a specific type of data if some non-match-anything implicit rule target matches it.
Since there are already built-in implicit rules for creating .c files (using parser generators for example), the match-anything rule is never considered.
The reason the error doesn't happen for the kernel makefiles is that they run make with -r, which eliminates built-in implicit rules. It's done in the top-level makefile by setting the MAKEFLAGS variable:
# Do not use make's built-in rules and variables
# (this increases performance and avoids hard-to-debug behaviour);
MAKEFLAGS += -rR
As a simple experiment, I created a file test.c_foo and the following makefile:
MAKEFLAGS += -r
%: %_foo
#echo building
make test.c without the first line gives
make: *** No rule to make target 'test.c'. Stop.
With the first line, it prints "building" instead.
I'm writing a static pattern rule to generate a list of dependencies for targets matching a pattern. The dependencies are generated through a shell command (the file content gives information about the dependencies). Here's an example of the explicit rule:
f1.o: $(shell gendep src/f1/f1.source)
... (some compilation command here) ...
While this works, I do not want to rewrite it for each new target since I'm maintaining the same file structure. My attempt at static pattern rule was like so:
%.o: $(shell gendep src/%/%.source)
...
I'm having trouble passing the stem (matched pattern for %) to the shell command. The shell command interprets it literally and operates on src/%/%.source, which of course doesn't exist.
I suspect there is way of passing the stem to the shell command but I don't seem to find it. Any experts here might be able to help me? Sorry if this is a newbie question (I'm indeed one).
What you're trying to do is difficult, because ordinarily Make will expand the $(shell ...) directive before running any rule, or even deciding which rules must be run. We can retard that by means of Secondary Expansion, a slightly advanced Make trick:
.SECONDEXPANSION:
%.o: $$(shell gendep src/$$*/$$*.source)
...
There are also other methods for automatic dependency generation.
Are there packages to color-highlight jags amd bugs model files? I have ESS installed, but it doesn't seem to recognize .bug files or jags/bugs syntax out of the box.
Syntax highlighting
I'm using ESS 5.14 (from ELPA) and syntax highlighting or smart underscore works fine for me with GNU Emacs 24.1.1. If you want to highlight a given file, you can try M-x ess-jags-mode or add a hook to highlight JAGS file each time, e.g.
(add-to-list 'auto-mode-alist '("\\.jag\\'" . jags-mode))
However, that is not really needed since you can simply
(require 'ess-jags-d)
in your .emacs. There's a corresponding mode for BUGS file. This file was already included in earlier release (at least 5.13), and it comes with the corresponding auto-mode-alist (for "\\.[jJ][aA][gG]\\'" extension).
(Please note that there seems to exist subtle issue with using both JAGS and BUGS, but I can't tell more because I only use JAGS.)
Running command file
If you want to stick with Emacs for running JAGS (i.e., instead of rjags or other R interfaces to JAGS/BUGS), there's only one command to know:
As described in the ESS manual, when working on a command file, C-c C-c should create a .jmd file, and then C-c C-c'ing again should submit this command file to Emacs *shell* (in a new buffer), and call jags in batch mode. Internally, this command is binded to a 'Next Action' instruction (ess-*-next-action). For example, using the mice data that comes with JAGS sample files, you should get a mice.jmd that looks like that:
model in "mice.jag"
data in "mice.jdt"
compile, nchains(1)
parameters in "mice.in1", chain(1)
initialize
update 10000
update 10000
#
parameters to "mice.to1", chain(1)
coda \*, stem("mice")
system rm -f mice.ind
system ln -s miceindex.txt mice.ind
system rm -f mice1.out
system ln -s micechain1.txt mice1.out
exit
Local Variables:
ess-jags-chains:1
ess-jags-command:"jags"
End:
Be careful with default filenames! Here, data are assumed to be in file mice.jdt and initial values for parameters in mice.in1. You can change this in the Emacs buffer if you want, as well as modify the number of chains to use.
I am working in MinGW environment (downloaded with their installer on 12/12/2011). I am attempting to compile a resource (.rc) file using Windres. The specific command I use is
Windres -O coff About1.rc -o About1.res
Windres generates at least 100 lines of warning messages reading: "warning: null characters ignored". Following this Windres emits: "Abouty1.rc:1:syntax error".
As a matter of fact, there are no null characters in the About1.rc file. In addtition, the first line of the file is an include statement: #include "dlgresource.h". I played around and eliminated this statement and it turns out that it doesn't matter what I put there, I get the same flurry of messages and the syntax error notification.
To make things more confusing, this same .rc file compiles without any problem using MSFT's rc.exe. The resulting .res file links smoothly with the program .obj file and runs perfectly.
I have no idea what is going on. Any ideas?
Thanks,
Mark Allyn
Your .rc file is probably encoded as UTF-16.
That's what's required in general by Microsoft's [rc.exe], in order to be able to deal with international characters, but GNU [windres.exe] can only deal with ANSI encoding.
One workaround is to convert the file to ANSI on the spot (possibly losing e.g. Russian or Greek characters):
> chcp 1252
Active code page: 1252
> type my.rc | windres --output-format=COFF -o my.res
> _
You probably used VS or a similar tool to generate the file. There are some parts of the character encodings that you cannot see resulting in null characters and etc.
Generate a new .res file with the same content, don't copy/paste the content, type it in yourself.
Try:
windres About1.rc -o About1.o
and then just use the resulting .o file instead of the originally intended .res file.
I've had the same troubles than you today. I know it has passed a lot of time from your question, but I'm writting this on the hope that it can be useful for someone.
First, I obtained an object file .o compiled using Cygwin, writting:
windres -o resource.o resource.rc
By doing that, you dont need to use the .res file, but the .o one, and you can then link this object with all the others, when you compile yout program, using GNU resources:
g++ Header_files CPP_files flags ... -o program.exe recource.o -lm
For instance.