I've noticed that if you have a Makefile, even an empty one, if you have a file called "install.sh" invoking "make install" will cause make to copy "install.sh" to "install" and set its permissions. How can I prevent this from happening?
Call make with option -r, i.e. make -r install. This disables the predefined rules.
EDIT
Of course, you can also override the shell rule only. Simply add
%: %.sh
# empty line
to your Makefile.
Related
I am trying to build a project that requires two include paths.
My command is:
./autogen.sh --prefix /usr/ --libdir /usr/lib/x86_64-linux-gnu/ CXXFLAGS="-I${TensorflowPath} -I${TensorflowPath}/tensorflow/lite/tools/make/downloads/flatbuffers/include" --enable-tflite
and I have set TensorflowPath to the correct path for my tensorflow source directory.
but the error I get is:
configure: error: unrecognized option: `-I/home/aaron/src/tensorflow/tensorflow/lite/tools/make/downloads/flatbuffers/include'
This is really maddening! The second or third option is always erroring out. Please advise !!
This autogen.sh script appears to be broken both conceptually by unifying two very distinct steps (generating configure with its related files and running configure) into one without good reason, and by the actual implementation of that broken concept using a broken way of passing command line arguments to the child configure process.
If you can replace the call to autogen.sh with a call to autoreconf -vis ., just do that and ignore the broken autogen.sh:
autoreconf -vis .
./configure CXXFLAGS="-Ifoo -Ibar" --prefix=/what/ever --and-so-on
make
make install
If you absolutely need to use that autogen.sh script and cannot just replace it with a call to autoreconf -vis ., call autogen.sh with the single parameter --help to prevent it from running configure with any consequences.
The single --help argument contains no spaces and thus even an autogen.sh script with shell quoting bugs should pass it on correctly to configure. Now autogen.sh should do its buildsystem setup first, and then run configure --help which does nothing but print a bunch of messages to the console.
Then you can run your actual configure command with the correct parameters afterwards:
./autogen.sh --help
./configure CXXFLAGS="-Ifoo -Ibar" --prefix=/what/ever --and-so-on
make
make install
I don't have idea that what is meaning of path-like target specification.
I would like to see execute commands in Makefile that generated by cmake to know that build process of clang.
I saw it with make -n command, it seems like executed other make command like following.
make -f utils/hmaptool/CMakeFiles/hmaptool.dir/build.make utils/hmaptool/CMakeFiles/hmaptool.dir/build
I have no idea what above make command do it.
In this command, target specification is path-like.(utils/hmaptool/CMakeFiles/hmaptool.dir/build)
What is meaning of this?
I know non-path-like target, for example make install or make clean and so on.
But I have no idea path-like target.
What is this??
The above command will use the makefile utils/hmaptool/CMakeFiles/hmaptool.dir/build.make, and will attempt to build the target utils/hmaptool/CMakeFiles/hmaptool.dir/build.
You will have to check the makefile to know what exactly build is. Probably a PHONY target to build everything in that folder.
I have a golang CLI program which generates a makefile to a specific project. While this works, there is an issue when the project already has a makefile. Of course I can check that in advance to avoid collusion, but how is it suggested to do it?
I'm not an expert in makefiles, but how can I create second makefile (maybe with the project name or something) that user can run via make (I guess with additional steps or info to the terminal)
You can generate it as Makefile.project and document to be run as make -f Makefile.project
You can give your Makefile whatever filename. Then make must be executed with parameter -f <your_filename> or --file=<your_filename>. See make manual on filenames.
Which version of make are you using? Some versions run special makefiles before others. For example, GNU make looks for the following files and runs the first one it finds: GNUmakefile, Makefile, makefile.
If you are using GNU make, then name your generated file GNUmakefile and add in the making any makefile already in the directory. That way, anyone running make in the directory will automatically run the generated makefike first.
I would like to run a makefile from another place in the file system. How do I pass the location of the makefile to make?
if I stand in "/" and I would like to run a makefile that resists in "/dir/dir2/dir3/makefile", how do I add that to the make command?
I tried:
make --file=dir/dir2/dir3/makefile
but it did not worked.
All relative paths in the makefile will be relative to your current directory and not the directory of the makefile.
Assuming that you understand that and what you want to do is still going to work then you want the -f flag to specify the makefile to use. (Which is in the man page, the manual and the --help output.)
If, instead, what you mean is you want to cd to somewhere else and run make then perhaps you are looking for (cd /some/path && make)?
You can use the -C flag to specify the path to your makefile. This way you can execute it from a different directory.
The -f flag has a different use. With that flag you can execute a makefile with a name other than makefile.
By default, when running make to compile a C source code file named prog.c
make prog
the default command that executes is
cc prog.c -o prog
Sometimes I really need to include some additional flags. I know that when there are no Makefiles, make relies on some environment variables.
On Ubuntu 14.04, how to configure these variables to change the command that gets executed by default?
Step by step answers will be appreciated!
When no makefile is present (or no rule exists in that makefile) make relies on a default built-in database of rules. Run make -p to get make to spit out all the rules it knows about (in the no makefile case that will be the default ones).
When you look at that list you will find a pattern rule for building C source into object files or executables. Those rules have variables in them (like CFLAGS, LDFLAGS, etc.) that can be used to control exactly what you are trying to. That's why they are there (and are why that default command has such funny spacing, in case you ever wondered about that).