Trying to remove a file prefix using the method proposed in this thread:
Remove prefix with make
but even with a copy paste, I'm getting make's missing separator error.
FILE=/a/thing #line 16
$(FILE:a/%=%) #line 17
Makefile:17: *** missing separator. Stop.
When GNU Make processes the following:
FILE=a/thing
$(FILE:a/%=%)
The $(FILE:a/%=%) is evaluated to thing. That's the problem.
What you want is probably:
removed-prefix=$(FILE:a/%=%)
That is, create a variable removed-prefix whose expansion results in thing, or:
FILE:=$(FILE:a/%=%)
Related
I'm trying to install libssh-0.8.5 onto Ubuntu 16.04 using the instructions from the install.readme provided. I follow every step as stated, but I get an error after executing the make command to build the project. The error is as follows:
[ 65%] Built target exec
tests/CMakeFiles/ssh_ping.dir/flags.make:8: *** target pattern contains no '%'. Stop.
CMakeFiles/Makefile2:1696: recipe for target 'tests/CMakeFiles/ssh_ping.dir/all' failed
make[1 ]: *** [tests/CMakeFiles/ssh_ping.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
I have researched and seen that it could be a syntax error somewhere in my make file that is preventing the build to continue. I have looked at the target make file giving the problem, but cant seem to identify what is causing the error.
The flag.make file is as follows:
The problem seems to be coming from the highlighted bold line. Can anyone see what I am missing?
On StackOverflow (and most other similar sites), please cut and paste text into your questions and format them using the proper markdown facilities, rather than attaching images containing text. The latter is difficult to read and we can't cut and paste it into our answer to show where things are going wrong.
You cannot embed newlines in quoted strings, in makefiles. Make is completely line-oriented and does not parse quotes at all. So to make this:
FOO = "bar
biz"
is not considered one line assigning a value containing a newline to a variable FOO. Instead, it's considered two lines, the first of which is assigning the value "bar to variable FOO and the second of which is a syntax error since make can't parse the string baz" as a valid command.
Apparently ssh wasn't installed properly on your platform, while cmake relies on it. I am a bit surprised that cmake itself did not raise an error when generating flag.make but as I don't use cmake I do not know whether it is its normal behaviour or not.
Anyway, when cmake tried to detect your version of OpenSSH it did it by running ssh and got an error message instead of the version number it wanted. This error message got inserted in the generated flag.make Makefile. Because the second line of this error message (I could copy-paste it here if it was not in a picture in your question) has the:
a: b: c
form, make tried to interpret it as a static pattern rule but as it contains no % wildcard character, make raised a syntax error.
What happens if you try to run /usr/bin/ssh -V on the command line?
I am trying to compile a fortran code. It will analyze an X file in an Y directory and then create a new file Z with the results. But there is something wrong occurring.
When I write the directory I see that it is too much for one line and then I try to continue it in the next one doing this:
namech='/home/matheus/Documents/UFABC/IC/Spectra/Elliptical/'
+ 'espec.fits'
But, when I try to compile using the command
gfortran Codigo.f -o TESTE -Lcfitsio -lcfitsio
I get this error message:
+ 'espec.fits'
1
Error: Invalid character in name at (1)
Can someone help me? Actually I do not know what this error is. The directory is 100% right. And when I move the archives to a simpler directory to be able to write everything in one line, it works! So is there something wrong with the "+"?
Thank you.
Edit1
Actually, when I add "&" in the end of the line, it gives me this error message:
namech='/home/matheus/Documents/UFABC/IC/Spectra/Elliptical/'&
1
Error: Unclassifiable statement at (1)
Codigo.f:60.7:
+ 'espec.fits'
1
Error: Invalid character in name at (1)
And with "//":
namech='/home/matheus/Documents/UFABC/IC/Spectra/Elliptical/'//
1
Error: Syntax error in expression at (1)
Codigo.f:60.7:
+ 'espec.fits'
1
Error: Invalid character in name at (1)
Edit2
Thank you so much for helping me. Well, I solved the problem switching to the ".f90" form.
Just one more question: do you know why it does not recognize the "c" for comments in the code? Thank you again! :)
This part of your compilation statement:
gfortran Codigo.f
will treat the source file, with its .f suffix, as fixed form source. This means that a continuation line is indicated by any character (other than a blank or a 0) in column 6.
However, the error message you get suggests that the + in the second line of your snippet is not in column 6 and that the compiler is treating it as the initial character in a new entity name for which it is not valid. The fact that the + is aligned, vertically, with n in the previous line strengthens my suspicion that this may the root of your problem.
Adding the ampersand, as suggested in a now-deleted answer, doesn't actually help in this case if you continue to tell the compiler that it is dealing with a fixed form source file. & is only used for continuation in free form source files. Adding the string-concatenation operator, //, doesn't help either since it is not followed by another string but a line ending. //& would help but is probably unnecessary.
I think you have 2 possible solutions, but choose only one:
Stick with fixed form and get the alignment right.
Change the file suffix to .f90 which will cause gfortran to treat the source file as free-form.
If you go for option 2 (which I would recommend) you can then either use & at the end of the continued line or you could simply merge the lines. In free-form the maximum line length is 132 characters.
Adding to High Performance Mark's answer:
If you continue with FORTRAN 77, most compilers have an option to increase the allowed line length, e.g., -ffixed-form -ffixed-line-length-none for gfortran. As already stated, Fortran >=90 has line length of 132, so you wouldn't need to split the line.
Finally, if you want to split the line in Fortran >=90, you need two ampersands. In most cases you need one, but to split a string you need two:
namech='/home/matheus/Documents/UFABC/IC/Spectra/Elliptical/&
&espec.fits'
We're generating make files for our source files and one of these files happens to have a '#' in its name.
The dependency statement in the make file looks like this:
./obj/abc/def#ghi.o: ./src/abc/def#ghi.pli
...
Which results in error:
Zeile 15: make: 1254-055 Abhängigkeitszeilen erfordern einen Doppelpunkt oder doppelten Doppelpunkt als Operator.
I tried to escape the '#' but neither single quotes, double quotes, one backslash or 2 backslashes work. Is there a way to fix this without renaming the file?
I'm afraid you're out of luck, especially with the AIX version of make.
The AIX Make documentation is here, and doesn't mention any way of escaping the # character.
The GNU Make documentation here mentions that it's possible:
If you want a literal #, escape it with a backslash (e.g., \#).
Comments may appear on any line in the makefile, although they
are treated specially in certain situations.
Is there any reason that you can't build GNU Make for AIX and use it instead of the AIX make?
In *.mak file I receive commands "commence before first target. Stop."
I didn't change it before.
How to solve this problem?
make (or NMAKE, or whatever flavour of make you are using) can be quite picky about the format of makefiles - check that you didn't actually edit the file in any way, e.g. changed line endings, spaces <-> tabs, etc.
This means that there is a line which starts with a space, tab, or some other whitespace without having a target in front of it.
if you have added a new line, Make sure you have added next line syntax in previous line. typically if "\" is missing in your previous line of changes, you will get this error.
Also, make sure you dont have a space after \ in previous line
Else this is the error
This could be echoing outside the target, for instance
# Variable
BAR =
ifeq ($(FOO), 1)
#echo "FooBar" <----- generate the error
BAR += foobar
endif
# Targets
all:
...
...
It's a simple Mistake while adding a new file you just have to make sure that \ is added to the file before and the new file remain as it is
eg.
Check Out what to do if i want to add a new file named customer.cc
This could also caused by mismatching brace/parenthesis.
$(TARGET}:
do_something
Just use parenthesises and you'll be fine.
I have a directory "FS2" that contains the following files:
ARGH
this
that
I have a makefile with the following contents.
Template:sh= ls ./FS2/*
#all: $(Template)
echo "Template is: $(Template)"
touch all
When I run "clearmake -C sun" and the file "all" does not exist, I get the following output:
"Template is: ./FS2/#ARGH# ./FS2/that ./FS2/this"
Modifying either "this" or "that" does not cause "all" to be regenerated. When run with "-d" for debug, the "all" target is only dependent on the directory "./FS2", not the three files in the directory. I determined that when it expands "Template", the "#" gets treated as the beginning of a comment and the rest of the line is ignored!
The problem is caused by an editor that when killed leaves around files that begin with "#". If one of those files exists, then no modifications to files in the directory causes "all" to be regenerated.
Although, I do not want to make compilation dependent on whether a temporary file has been modified or not and will remove the file from the "Template" variable, I am still curious as to how to get this to work if I did want to treat the "#ARGH#" as a filename that the rule "all" is dependent on. Is this even possible?
I have a directory "FS2" that contains the following files: #ARGH# ...
Therein lies your problem. In my opinion, it is unwise using "funny" characters in filenames. Now I know that those characters are allowed but that doesn't make them a good idea (ASCII control characters like backspace are also allowed with similar annoying results).
I don't even like spaces in filenames, preferring instead SomethingLikeThis to show independent words in a file name, but at least the tools for handling spaces in many UNIX tools is known reasonably well.
My advice would be to rename the file if it was one of yours and save yourself some angst. But, since they're temporary files left around by an editor crash, delete them before your rules start running in the makefile. You probably shouldn't be rebuilding based on an editor temporary file anyway.
Or use a more targeted template like: Template:sh= ls ./FS2/[A-Za-z0-9]* to bypass those files altogether (that's an example only, you should ensure it doesn't faslely exclude files that should be included).
'#' is a valid Makefile comment char, so the second line is ignored by the make program.
Can you filter out (with grep) the files that start with # and process them separately?
I'm not familiar with clearmake, but try replacing your template definition with
Template:sh= ls ./FS2/* | grep -v '#'
so that filenames containing # are not included in $(Template).
If clearmake follows the same rules as GNU make, then you can also re-write your target using something like Template := $(wildcard *.c) which will be a little more intelligent about files with oddball names.
If I really want the file #ARGH# to contribute to whether the target all should be rebuilt as well as be included in the artifacts produced by the rule, the Makefile should be modified so that the line
Template:sh= ls ./FS2/*
is changed to
Template=./FS2/*
Template_files:sh= ls $(Template)
This works because $(Template) will be replaced by the literal string ./FS2/* after all and in the expansion of $(Template_files).
Clearmake (and GNU make) then use ./FS2/* as a pathname containing a wildcard when evaluating the dependencies, which expands in to the filenames ./FS2/#ARGH# ./FS2/that ./FS2/this and $(Template_files) can be used in the rules where a list of filenames is needed.