I want to make certain programs only if the SSE instruction set is supported on the machine where make is run (native target). Assuming it runs linux,
grep sse /proc/cpu_info | wc -l
returns 0 if SSE instructions are not supported and >0 otherwise. But how can I use that in my makefile to facilitate conditional makes?
I currently use GNU Make 3.81, running on linux.
In traditional GNU usage, you wouldn't let make do this job, but rather configure, which writes its output into a Makefile. After all, you don't want to re-check your environment every time you run make - in the best case, you waste time rechecking an unchanged environment, and in the worst, your build gets inconsistent.
That said, a make-only solution would look like:
HAVE_SSE=$(filter-out 0,$(shell grep sse /proc/cpu_info | wc -l))
CFLAGS+=$(if $(HAVE_SSE),-msse)
ifneq ($(HAVE_SSE),)
sse-target
endif
The shell function expands to the shell command's output. The filter-out makes the non-SSE output an empty string instead of 0 because that's easier to conditionalize. Then, you can use the if function as indicated to have conditionals on the value.
So I figured out a (working!) solution by myself, similar to the suggestion by thiton:
SSE := $(shell grep sse /proc/cpuinfo)
INVALID := $(shell grep non-sense /proc/cpuinfo)
ifneq ($(INVALID),$(SSE))
sse_target
endif
Related
In a Makefile, reading user input terminated by <ENTER> can be implemented by using (the shell function) read. On the shell (bash), reading a single character can be done with read -n 1. However, I was surprised that read -n 1 didn't seem to work with GNU Make 4.2.1. Do I miss some escaping here?
Bash:
$> echo x | read -n 1 mychar; echo 'you typed '$mychar
you typed x
Makefile:
all:
read -n 1 mychar; echo 'you typed '$$mychar
Make:
$> echo x | make
read -n 1 mychar; echo 'you typed '$mychar
/bin/sh: 1: read: Illegal option -n
Does make provide its own version of read ?
System: GNU Make 4.2.1, Ubuntu 20.04.3 LTS
PS: I am aware that user interaction is considered bad style, and it clearly should not be used in configuration workflows. However, it comes in quite handy for targets associated with pruning, resetting or deleting data (e.g., make clear). And asking for y/N confirmation gives you a chance to tell your users what it will take them to rebuild what they are going to remove.
PPS: I know that the regular read gives you almost the same functionality, except that you need to hit <ENTER>. This question about getting a better understanding for the relationship between make and its shell enviroment.
NB: This problem is different from Makefile - Why is the read command not reading the user input?. They just didn't properly escape the variable.
Purpose:
Save a program that writes data to disk from vain attempts of writing to a full filesystem;
Save bandwidth (don't download if nowhere to store);
Save user's and programmer's time and nerves (notify them of the problem instead of having them tearing out their hair with reading misleading error messages and "why the heck this software is not working!").
The question comes in 2 parts:
Reporting storage space statistics (available, used, total etc.), either of all filesystems or of the filesystem that path in question belongs to.
Reporting a filesystem error on running out of space.
Part 1
Share please NATIVE Raku alternative(s) (TIMTOWTDIBSCINABTE "Tim Toady Bicarbonate") to:
raku -e 'qqx{ df -P $*CWD }.print'
Here, raku -executes df (disk free) external program via shell quoting with interpolation qqx{}, feeding -Portable-format argument and $*CWD Current Working Directory, then .prints the df's output.
The snippet initially had been written as raku -e 'qqx{ df -hP $*CWD }.print' — with both -human-readable and -Portable — but it turned out that it is not a ubiquitously valid command. In OpenBSD 7.0, it exits with an error: df: -h and -i are incompatible with -P.
For adding human-readability, you may consider Number::Bytes::Human module
raku -e 'run <<df -hP $*CWD>>'
If you're just outputting what df gives you on STDOUT, you don't need to do anything.
The << >> are double quoting words, so that the $*CWD will be interpolated.
Part 1 — Reporting storage space statistics
There's no built in function for reporting storage space statistics. Options include:
Write Raku code (a few lines) that uses NativeCall to invoke a platform / filesystem specific system call (such as statvfs()) and uses the information returned by that call.
Use a suitable Raku library. FileSystem::Capacity picks and runs an external program for you, and then makes its resulting data available in a portable form.
Use run (or similar1) to invoke a specific external program such as df.
Use an Inline::* foreign language adaptor to enable invoking of a foreign PL's solution for reporting storage space statistics, and use the info it provides.2
Part 2 — Reporting running out of space
Raku seems to neatly report No space left on device:
> spurt '/tmp/failwrite', 'filesystem is full!'
Failed to write bytes to filehandle: No space left on device
in block <unit> at <unknown file> line 1
> mkdir '/tmp/failmkdir'
Failed to create directory '/tmp/failmkdir' with mode '0o777': Failed to mkdir: No space left on device
in block <unit> at <unknown file> line 1
(Programmers will need to avoid throwing away these exceptions.)
Footnotes
1 run runs an external command without involving a shell. This guarantees that the risks attendant with involving a shell are eliminated. That said, Raku also supports use of a shell (because that can be convenient and appropriate in some scenarios). See the exchange of comments under the question (eg this one) for some brief discussion of this, and the shell doc for a summary of the risk:
All shell metacharacters are interpreted by the shell, including pipes, redirects, environment variable substitutions and so on. Shell escapes are a severe security concern and can cause confusion with unusual file names. Use run if you want to be safe.
2 Foreign language adaptors for Raku (Raku modules in the Inline:: namespace) allow Raku code to use code written in other languages. These adaptors are not part of the Raku language standard, and most are barely experimental status, if that, but, conversely, the best are in great shape and allow Raku code to use foreign libraries as if they were written for Raku. (As of 2021 Inline::Perl5 is the most polished.)
In my continuous integration testing for my emacs package fsharp-mode, I am adding byte-compilation to the tests, in order to have immediate feedback. I am roughly using:
emasc -batch batch-byte-compile *.el
This returns non-zero if there is an error, but not if it is just a warning. I would like to be alerted also if there are any warnings, as this may include calls to undefined functions (which has happened before thanks to a typo).
So: how can I obtain a non-zero return code in case of compilation warnings?
You can set byte-compile-error-on-warn to a non-nil value, as in:
$ emacs -Q --batch \
--eval '(setq byte-compile-error-on-warn t)' \
-f batch-byte-compile *.el
The byte compiler now stops at the first warning, though, so you should make this setting optional in your Makefile, and only use it in your CI setup.
If you need more sophisticated control than that, you have to write your own post-processor, e.g. a Python script that parses the output of the byte compiler and adjusts the exit code and/or output accordingly, or write your own batch-byte-compile variant that does more sophisticated processing.
I want (GNU) make to rebuild when variables change. How can I achieve this?
For example,
$ make project
[...]
$ make project
make: `project' is up to date.
...like it should, but then I'd prefer
$ make project IMPORTANTVARIABLE=foobar
make: `project' is up to date.
to rebuild some or all of project.
Make wasn't designed to refer to variable content but Reinier's approach shows us the workaround. Unfortunately, using variable value as a file name is both insecure and error-prone. Hopefully, Unix tools can help us to properly encode the value. So
IMPORTANTVARIABLE = a trouble
# GUARD is a function which calculates md5 sum for its
# argument variable name. Note, that both cut and md5sum are
# members of coreutils package so they should be available on
# nearly all systems.
GUARD = $(1)_GUARD_$(shell echo $($(1)) | md5sum | cut -d ' ' -f 1)
foo: bar $(call GUARD,IMPORTANTVARIABLE)
#echo "Rebuilding foo with $(IMPORTANTVARIABLE)"
#touch $#
$(call GUARD,IMPORTANTVARIABLE):
rm -rf IMPORTANTVARIABLE*
touch $#
Here you virtually depend your target on a special file named $(NAME)_GUARD_$(VALUEMD5) which is safe to refer to and has (almost) 1-to-1 correspondence with variable's value. Note that call and shell are GNU Make extensions.
You could use empty files to record the last value of your variable by using something like this:
someTarget: IMPORTANTVARIABLE.$(IMPORTANTVARIABLE)
#echo Remaking $# because IMPORTANTVARIABLE has changed
touch $#
IMPORTANTVARIABLE.$(IMPORTANTVARIABLE):
#rm -f IMPORTANTVARIABLE.*
touch $#
After your make run, there will be an empty file in your directory whose name starts with IMPORTANTVARIABLE. and has the value of your variable appended. This basically contains the information about what the last value of the variable IMPORTANTVARIABLE was.
You can add more variables with this approach and make it more sophisticated using pattern rules -- but this example gives you the gist of it.
You probably want to use ifdef or ifeq depending on what the final goal is. See the manual here for examples.
I might be late with an answer, but here is another way of doing such a dependency with Make conditional syntax (works on GNU Make 4.1, GNU bash, Bash on Ubuntu on Windows version 4.3.48(1)-release (x86_64-pc-linux-gnu)):
1 ifneq ($(shell cat config.sig 2>/dev/null),prefix $(CONFIG))
2 .PHONY: config.sig
3 config.sig:
4 #(echo 'prefix $(CONFIG)' >config.sig &)
5 endif
In the above sample we track the $(CONFIG) variable, writing it's value down to a signature file, by means of the self-titled target which is generated under condition when the signature file's record value is different with that of $(CONFIG) variable. Please, note the prefix on lines 1 and 4: it is needed to distinct the case, when signature file doesn't exist yet.
Of course, consumer targets specify config.sig as a prerequisite.
It seems as if a script with #! prefix can have the interpreter name and ONLY one argument. Thus:
#!/bin/ls -l
works, but
#!/usr/bin/env ls -l
doesn't
Do you agree? Any thoughts?
Francesc
Different Unixes interpret #! differently. Here's a comprehensive-looking writeup: http://www.in-ulm.de/~mascheck/various/shebang/
It seems that the lowest common denominator across platforms is "the interpreter (which must not itself be a script) and no more than one argument".
Originally, we only had one shell on Unix. When you asked to run a command, the shell would attempt to invoke one of the exec() system calls on it. It the command was an executable, the exec would succeed and the command would run. If the exec() failed, the shell would not give up, instead it would try to interpret the command file as if it were a shell script.
Then unix got more shells and the situation became confused. Most folks would write scripts in one shell and type commands in another. And each shell had differing rules for feeding scripts to an interpreter.
This is when the “#! /” trick was invented. The idea was to let the kernel’s exec () system calls succeed with shell scripts. When the kernel tries to exec () a file, it looks at the first 4 bytes which represent an integer called a magic number. This tells the kernel if it should try to run the file or not. So “#! /” was added to magic numbers that the kernel knows and it was extended to actually be able to run shell scripts by itself. But some people could not type “#! /”, they kept leaving the space out. So the kernel was expended a bit again to allow “#!/” to work as a special 3 byte magic number.