I am trying to find a way to define a path to .deps which stores the .Po files. I want it to be in obj instead of my src directory.
I am struggling in finding a way to define the path. I came to know that it is the DEPDIR which stores the path to .deps but where do I do it is unsure. Do we set it up in configure.ac or in Makefile.am;
Any help is appreciated. Thanks.
What you're trying to do is not feasible with automake. You As ptomato suggested you should use an out-of-tree build if you don't want your source path to be "dirtied" by the build.
Related
I'm trying to ensure that some non-source files are generated when make dist is executed. The files are an info file and an index which is constructed from the info file. I find that the files are generated when I execute make install but not when I execute make dist.
Here is the Makefile.am. (This is share/logic/Makefile.am in the Maxima project, if anybody cares.)
all-local: info
info: logic.info logic-index.lisp
logic.info: logic.texi
makeinfo --force logic.texi
logic-index.lisp: logic.info
perl ../../doc/info/build_index.pl $< > $#
Somehow I got the idea that the target all-local could cause the info and index to be rebuilt. That works OK for make install -- I guess all-local is a target for that. But all-local is not, it appears, a target for make dist. What other target could I use to ensure that the logic.info and logic-index.lisp are rebuilt for make dist as well as make install?
I have searched the web, and SO, and tried some random things, but so far I've come up empty-handed. Thanks in advance for your help.
I'm working with GNU make 3.81, GNU automake 1.14.1, and GNU autoconf 2.69, on Ubuntu 14.04.
You can force something to be built and included in the package by using EXTRA_DIST, so in your case
EXTRA_DIST = logic-index.lisp
This will cause the file to be always included in the distribution tarball.
Right now I'll just run go build __.go, but I'm wondering if it's possible to have that file built in a subdirectory (e.g. a /bin folder). It would just make gitignoring the binary files a lot cleaner, and right now I'm not really sure what else is a good approach as I'm also struggling to create a working gitignore exception rule that isn't just "Ignore all files, except .go files".
My current solution is naming the binary files every time I build them (e.g. go build -o hello.bin hello.go), but this seems laborious.
you can use the -o flag.
cd to the directory where you have the main.go file.
use this command - go build -o DirectoryPath
Where DirectoryPath is the location where you want to create the binary file to.
Instead of using go build *.go, you can do following:
Setup Go workspace, using this official go resource: How to write go code
Define GOBIN and GOPATH environment variable.GOBIN environment variable will point to the directory where you want to store your executables.GOPATH environment variable will point to the directory, where you've setup go workspace.
Now, instead of doing go build *.go, you can use go install {YourCodePath}, where {YourCodePath}, is relative path of your code in go workspace. And if the build is successful, you can find your executable in directory, pointed by GOBIN.
Has anyone seen something like this:
when running make in a project using autotools, it always rebuils everyhing. Running with make -d, shows that make looks for foo.lo files and because they are not found, always recompiles foo.c.
It seems to be related to builddir != srcdir.
The .lo files are of course in the builddir. But apparently make or libtool are expecting them somewhere else:
Debug output lookgs like this:
Prerequisite /path/to/srcdir/foo.h' is older than targetfoo.lo'.
/path/to/builddir/.deps/foo.Plo:1 Must remake target `foo.lo'.
Update It seems the problem is caused by AC_PROG_LIBTOOL. According to the documentation it expects a variable called top_builddir to be set to the builddirectory. What is the standard way to set it? Is there a autoconf macro for this?
A libtool update solved this problem
I am trying to compile c-sources with the configure, make, make install trilogy.
Since I want to compile the sources so that they use another library (XYZ) that is not used by default, I can specify that with a
./configure --with-XYZ=yes
However, for the moment, XYZ is not installed in a default location, so I guess I can specify the path to the location of XYZ with that same configure script. If my guess is right, I'd appreciate if someone could point me towards the right direction of how to do that.
Specify the library path on the command line like this:
./configure --with-XYZ=yes LDFLAGS=-L/path/to/xyz
The most general way is to specify the LDFLAGS (for -L) and CPPFLAGS (for -I) variables, like ptomato described.
In many cases, there are other ways that are specific to the option and the package that provides it. Sometimes it might be --with-XYZ=PATH, sometimes it could be --with-XYZ-path=PATH, sometimes pkg-config is involved. You need to read the particular installation documentation, or more often than not do some detective work.
In my Makefile.am, I have
SUBDIRS = libltdl .
This is because I want to be able to use the version of libltdl included with my package (i.e. ./configure --with-included-ltdl). However, I occasionally run into the problem where make invokes itself recursively forever. Unfortunately I'm not sure exactly what conditions cause this to occur.
This is usually solved by rerunning autoconf and configure. I'd like to know the "proper" way of doing this, because it seems this isn't it. (I also find after I update configure.ac that I have to run autoreconf && autoreconf libltdl instead of just autoreconf)
Thanks for the help!
Once again, I spoke too soon. This seems to be solved by moving the source into a separate directory (i.e. src) and then updating SUBDIRS to libltdl src.