Why does gnu make delete this file? - gnu-make

Consider this Makefile:
.PHONY: all
all: main.txt
main.txt: build/main.txt
cp build/main.txt .
%/main.txt: %/data.txt
cp $*/data.txt $*/main.txt
%/data.txt:
touch $*/data.txt
After running make, build/data.txt is removed automatically. Why is this the case?
I tried adding .PRECIOUS: build/% to the file, but it it not help, the file was still removed. How can I prevent this?

According to the GNU Make documentation
You can also list the target pattern of an implicit rule (such as ‘%.o’) as a prerequisite file of the special target .PRECIOUS to preserve intermediate files created by rules whose target patterns match that file’s name.
the prerequisite for.PRECIOUS needs to be the (exact) target pattern of an existing implicit rule.
In your case this would be %/data.txt instead.
The documentation hints at this, but is not particularly clear about it.
As a side note: As far as I can tell build/main.txt is not automatically deleted since it is explicitly named as a prerequisite for the main.txt target and build/data.txt is automatically deleted since it is never explicitly named.

Related

GNU make: include file only if target is not "clean"

Using GNU make, I want to include a file, except if the current target is "clean".
That is, I want to do the equivalent of the following:
ifneq($(TARGET),clean)
-include somefile.txt
endif
But for that, I need a variable whose value is the target given on the command line (here named $(TARGET)). Such a variable does not seem to exist, and I can understand why, because you could have multiple targets on the command line, some of which you might want to include the file for, and others not. Actually, it would be fine if the file is included when there are other targets besides "clean". The only real problem I currently have is that when the file to be included does not exist, Make will try to build it, which is unnecessary when you're about to delete it again when executing the "clean" target.
So, is there another way to accomplish what I want?
You can use MAKECMDGOALS. Use it like this to handle multiple arguments on the command line:
ifeq (clean,$(filter clean,$(MAKECMDGOALS)))
-include somefile.txt
endif
However, this is often fraught because if you run make clean all or whatever, the include file won't be included even though it might be needed for all.
If you really need this to be reliable another way is to use recursion for your "top-level" arguments, running them one at a time in a sub-make.
You could usefully check that if clean is a target then it is the only target. Otherwise strange things can go wrong silently causing much wailing and gnashing of teeth. My most recent Makefile includes the following. (NB tested but not as yet used extensively).
ifeq (clean,$(filter clean,$(MAKECMDGOALS)))
ifneq($(strip $(filter-out clean,$(MAKECMDGOALS)))
$(error ERROR: can not make other targets with clean
endif
endif

How do /** and /* differ in terms of directory navigation in Grunt?

This is quite an easy one for you guys, but I can't find a definitive/formal answer to this question.
Suppose we are in directory A. Then,
"A/* " probably means: Every file and folder directly inside A.
"A/** " then may mean: Every file and folder inside A, and every file and folder directly inside every child that is directly inside A. (Basically, an extension of /* operator that traverses one level deeper of the root folder? aka "/** " = "/* /* " )
My "directly inside" terminology might be wrong. May be its better to say "direct child" or something, but you get the idea.
Then, what does "A/**/* " mean? Is it equal to "A/* /* /* " ?
Although this seems basic, its quite confusing when I don't have a formal definition of the operators.
I'm currently using Javascript and trying to modify a Gruntfile. But I guess these operators may come up in any context.
This behavior is not intrinsic to JavaScript and is not related to any operators: as far as JavaScript is concerned, it is just a string.
The handling of such glob expansion is determined by the specific library/consumer. For gruntjs it is covered in Grunt Globbing Patterns:
It is often impractical to specify all source filepaths individually, so Grunt supports filename expansion (also know as globbing) via the built-in node-glob and minimatch libraries ..
* matches any number of characters, but not /
** matches any number of characters, including /, as long as it's the only thing in a path part
All most people need to know is that foo/*.js will match all files ending with .js in the foo/ subdirectory, but foo/**/*.js will match all files ending with .js in the foo/ subdirectory and all of its subdirectories.
As such (but refer to the specific documentation!), /**/ generally means "match any depth of directories" and /*/ or /* means "match a single directory or file part".
The gruntjs documentation is a bit vague on the specific mechanics of ** in the standard "/**/*.x" pattern, but referring to node-glob says:
If a "globstar" (**) is alone in a path portion, then it matches zero or more directories and subdirectories searching for matches. It does not crawl symlinked directories.
[.. The double-star character] is supported in the manner of bsdglob and bash 4.3, where ** only has special significance if it is the only thing in a path part. That is, a/**/b will match a/x/y/b, but a/**b will not.
Using this knowledge we get the equivalency (when used as a path component), of A/**/f with A/f, A/*/f, A/*/*/f, etc for every number of intermediate directories.
If you see A/**/* that means to recursively search all the way down the tree of every folder under folder A. For more information look up basic linux style file commands.

Qt internationalization and CMake: how to update *.ts and don't lose them

I'm having this CMakeLists.txt in directory with translation files (*.ts):
SET(TRANSLATIONS
lang_de.ts
lang_en.ts
)
FIND_PACKAGE(Qt5LinguistTools)
QT5_ADD_TRANSLATION(QM_FILES ${TRANSLATIONS})
SET(QM_FILES ${QM_FILES} PARENT_SCOPE)
ADD_CUSTOM_TARGET (translations ALL DEPENDS ${QM_FILES})
It builds *.qm files from specified *.ts.
But I want to improve this and get two custom targets, which won't built automatically.
One for appending new strings from sources into ts files, and one for refreshing ts. The last one would update ts from sources and remove obsolete strings from ts.
I've tried to add this after lines above:
ADD_CUSTOM_TARGET (
ts_append
COMMAND QT5_CREATE_TRANSLATION(QM_FILES ${CMAKE_SOURCE_DIR}/src/app ${TRANSLATIONS} OPTIONS -I ${CMAKE_SOURCE_DIR}/src)
)
ADD_CUSTOM_TARGET (
ts_refresh
COMMAND QT5_CREATE_TRANSLATION(QM_FILES ${CMAKE_SOURCE_DIR}/src/app ${TRANSLATIONS} OPTIONS -no-obsolete -I ${CMAKE_SOURCE_DIR}/src)
)
but it seems I can't use QT5_CREATE_TRANSLATION macro inside custom target, isn't it?
Maybe I'm on wrong way, how would you solve this problem: easy updating of ts and don't lose them after make clean?
To solve the make clean problem, add a sub directory (ADD_SUBDIRECTORY(translations)) and add SET_DIRECTORY_PROPERTIES(PROPERTIES CLEAN_NO_CUSTOM 1) to the contained CMakeLists.txt.
See here for an example of that.
For the second part of your question there are two possible ways to do it. Either use FILE(WRITE <filename> "QT5_CREATE_TRANSLATION(QM_FILES ${SOURCE_DIR}/src/app ${TRANSLATIONS} OPTIONS -I ${SOURCE_DIR}/src)") and then use COMMAND ${CMAKE_COMMAND} -DSOURCE_DIR=${CMAKE_SOURCE_DIR} -DTRANSLATIONS=${TRANSLATIONS} <filename> in add_custom_target. I doubt there's a good way of retrieving the contents of QM_FILES though.
The second option is creating two additional sub directories, each with a QT5_CREATE_TRANSLATIONS and a ADD_CUSTOM_TARGET call.

GNU Make: disable all built-in rules, except desired ones

Twice in the past, GNU make has destroyed my work because some of its built-in rules have .c files as a target.
If you have a file called foo.c, and also a foo.l Lex scanner or foo.y Yacc parser, watch out! GNU make assumes that the .c file is a target made from these (it's evidently a POSIX requirement!), and it will will do something like mv y.tab.c foo.c or lex -t foo.l > foo.c.
What is the way to disable all such hidden, dangerous rules (whether known or unknown) while keeping the useful ones?
Specifically, how can we give this request to GNU Make: "please retain all your rules related to (for example) .c and .o files, and disable all rules which involve any other file type"?
From the manual:
Many of the predefined implicit rules are implemented in make as
suffix rules, so which ones will be defined depends on the suffix list...
If you modify the suffix list, the only predefined suffix rules in
effect will be those named by one or two of the suffixes that are on
the list you specify; rules whose suffixes fail to be on the list are
disabled...
If you wish to eliminate the default known suffixes instead of just
adding to them, write a rule for .SUFFIXES with no prerequisites. By
special dispensation, this eliminates all existing prerequisites of
.SUFFIXES. You can then write another rule to add the suffixes you
want.
.SUFFIXES: # Delete the default suffixes
.SUFFIXES: .c .o # Define a new suffix list

make does not realize that a relative path name dependency is the same as an absolute pathname target

The following is a simplified makefile for a problem I'm having:
all: /tmp/makey/../filey
#echo All done
/tmp/filey:
#echo Filey
When I run make it says:
make-3.79.1-p7: * No rule to make target /tmp/makey/../filey', needed byall'. Stop.
Clearly it does not realize that /tmp/makey/../filey is the same as /tmp/filey. Any ideas how I can make this work?
Thanks
Ciao
-- Murali
Newer versions of GNU make have $(abspath ...) and $(realpath ...) functions you can apply to your prerequisites and targets to resolve the paths to the same string. If you've constructed these names yourself (for example, $(PREFIX)/../filey) then you can use $(dir $(PREFIX))filey instead.
Other than that, there's no way to solve this problem. Make uses string matching on targets and if the strings are not identical, they don't match (there's a special case to ignore the simple prefix ./) Even if make understood this distinction (by applying abspath itself to each target name, maybe) it would still not help in the face of symbolic links for example.
The only "real" answer would be for make to understand something about the underlying file system (device IDs and inodes for example) that let you talk about files without referring to their pathname. However, in a portable program like make doing this is problematic.

Resources