[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using Emacs with Autotools projects : separate source and binaries d

From: Bob Proulx
Subject: Re: Using Emacs with Autotools projects : separate source and binaries directories
Date: Sun, 9 Nov 2008 14:18:30 -0700
User-agent: Mutt/1.5.13 (2006-08-11) wrote:
> > How are you separating these?  I think that may be the cause of this
> > next problem that you mention.
> MyProject/src
> MyProject/bin
> MyProject/bin/linux
> MyProject/bin/windows


> AC_CONFIG_SRCDIR(src/main.cpp)
> No VPATH customization.

VPATH is built into automake and isn't something that needs
customization.  AFAIK.

> Compilation:
> ~MyProject : cd bin/linux
> ~MyProject : ../../configure
> ~MyProject : make

Seems reasonable enough.  Instead of bin I would probably use build
but that is just personal preference.  Instead of linux I would use
a full system tuple.  Because linux is a kernel that runs on more
different architectures than any other kernel and many different
operating systems use it as their main kernel.


> I see the problem right now, but I don't understand it. And I really
> don't know how to solve it !

I can see that you are using autoconf.  Are you also using automake?
If so then you might post your question to the automake mailing list
(as Ralf also suggested) because I don't think this is really an emacs
issue.  I think this is just some quirk of how you are building your

Note that automake and autoconf have different mailing lists and
although work together in the autotools collection they are actually
quite different in detail.  autoconf is a very portable collection of
shell scripts that run on almost every platform possible in order to
configure a project build.  automake is a set of perl scripts that run
on the developer machines (and therefore does not need to be portable,
it requires perl, etc.) to generate which can run on
portable make.  The generated files are processed by
autoconf into Makefile files which should run on almost every system
using portable make.  I suspect that your issue is with using

> In fact, I have the next source tree:
> MyProject/src/
> MyProject/src/libcore
> MyProject/src/plugins
> MyProject/src/tests
> If I have an error in MyProject/src/libcore and I am running make in
> MyProject/bin/linux/src/libcore, source code is correctly found.


> If I have an error in MyProject/src/plugins and I am running make in
> MyProject/bin/linux/src/plugins, source code is correctly found.
> Same for the test directory.


> But, I have an error in MyProject/src/libcore and I am running make in
> MyProject/bin/linux/src, source code is not found anymore.
> This is weird and unpractical.

Yes.  This is strange.  I do not see this.

> Do you anderstand this behaviour ?

Sorry but no I do not.  This is where I was suggesting that you try
your test with an already 

  $ wget
  $ tar xzvf hello-2.3.tar.gz
  $ mkdir hello-2.3-mybuild
  $ cd hello-2.3-mybuild
  $ ../hello-2.3/configure 
  $ make

That should build successfully.  (If it doesn't please report it to
the bug-hello project. :-)

Then insert a known error.  Insert a preprocessor error directive to
force the next compile to fail in a known way.  This will set up the
test case.

  $ echo '#error forced error here' >> ../hello-2.3/src/hello.c

Then compile inside emacs again.

  M-x compile

When I do this I get the following output in the emacs *compilation*

  Making all in src
  make[2]: Entering directory `/var/tmp/hello-2.3-mybuild/src'
  gcc -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -I. -I.. 
-I../../hello-2.3/src  -I../../hello-2.3/gnulib/lib -I../gnulib/lib   -g -O2 
-MT hello.o -MD -MP -MF .deps/hello.Tpo -c -o hello.o 
  ../../hello-2.3/src/hello.c:194:2: error: #error forced error here
  make[2]: *** [hello.o] Error 1
  make[2]: Leaving directory `/var/tmp/hello-2.3-mybuild/src'
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory `/var/tmp/hello-2.3-mybuild'
  make: *** [all] Error 2

In emacs running C-x ` takes me to the next error.

If I have understood things correctly this will recreate your test
case.  The error is in the same directory relationship (up one and
down two) to what you are reporting.  But this is a case that is known
and other people can recreate.

> I have a little more question about Emacs configuration.
> When I was building binaries in the source directory, I was running
> 'make' in the directory of the current file.
> It was simple.

Yes.  Simple.  I dare say that way is the most common way to build.
It is what I prefer personally.  If I need a second build for
something different I personally prefer to check out an additional
copy of the source code in a different directory.  However other
people prefer to share the source directory.  Sometimes this is
because they have a *HUGE* source checkout making it painful to
checkout multiple copies of it.

> Since Makefiles have moved, I am running 'make' in src directory.
> Is it a good idea ?

Huh?  There are no Makefiles in the source directory.

  $ ls -ldog hello-2.3*
  drwxrwxr-x 10   4096 2007-06-29 14:29 hello-2.3/
  drwxrwxr-x  9   4096 2008-11-09 14:03 hello-2.3-mybuild/
  -rw-rw-r--  1 431983 2007-06-29 14:39 hello-2.3.tar.gz

  $ find hello-2.3* -name Makefile

Because we are setting up a VPATH build we are running configure in
the build directory.  The configure operation is creating Makefiles
only in the build directory.

The source directory does have and files:

  $ find hello-2.3* -name Makefile.*

In order to share the source between multiple builds using automake
you configure in the build directory and create Makefile files there.
Then you run make in the build directory.

I am hoping that you will be able to recreate a good working result
using the GNU hello project as an example.  If not then please do keep
asking questions.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]