1
votes

This question extends question How to handle subprojects with autotools?

So I have some project with its own Makefile (not GNU autotools) in modules/libfoo

I added SUBDIRS = include/jsonbox Makefile.am and it compiles fine, but only if I invoke ./configure and make from top dir.

If I create a subdir, say build, and run ../configure from it I got an error during make:

   Making all in modules/libfoo
   /bin/sh: line 17: cd: modules/libfoo: No such file or directory
   make: *** [all-recursive] Error 1

Is it possible to handle this? I need several build dirs for different archs and CFLAGS.

EDIT: As it sugected in docs I created a GNUmakefile.in in a nested project. But it still doesn't work with VPATH:

Making all in modules/libfoo
make[1]: Entering directory `/home/galadog/test/build/moudles/libfoo'
GNUmakefile:2: Makefile: No such file or directory
make[1]: *** No rule to make target `Makefile'.  Stop.
make[1]: Leaving directory `/home/galadog/test/build/moudles/libfoo'
make: *** [all-recursive] Error 1

Edit2 The actual Makefile can be seen here: https://github.com/anhero/JsonBox/blob/master/Makefile

1
Can you modify the Makefile of that sub-project or is it a third-party Makefile?Michał Górny
@michal-gorny it is the worst case, but if there no other solution I can.galadog
Could you paste that Makefile for us? Maybe it has some kind of build-dir/VPATH support already but honestly I doubt it.Michał Górny
@MichałGórny see updated postgaladog

1 Answers

1
votes

Sadly, you can't achieve this correctly without either:

  1. Modifying/replacing the upstream Makefile,
  2. Adding your own make rules for the upstream library and ignoring their Makefile.

The docs you linked are mostly focused on working around the issues with make distcheck, without supporting actual builds.

There's, however, one simple hack which would work with minimal work required -- it is to copy the whole sub-tree to the build directory. It is not a very good solution but it will make sub-tree builds working:

SUBDIRS = modules/libfoo

# and possibly all other -recursive targets you'll be using
all-recursive: copy-libfoo

copy-libfoo:
    mkdir -p modules
    cp -R -H $(top_srcdir)/modules/libfoo modules/

But as I said, it's ugly. The upstream Makefile still needs to define correct automake targets (all, install etc.), so in your case you would as well to need to add a GNUmakefile in the project subdir like:

include Makefile
INSTALL:

which would provide a dummy target to avoid *** No rule to make target 'install'; and possibly that as well. Then EXTRA_DIST if you want to use make dist but that's all covered in the linked doc.


Honestly, you're on a slippery ground. If I were you, I would either simply not use that project and ignore it because maintaining it will be harder than writing the same thing from scratch.

The second solution I would consider, and one which would work correct would be to duplicate the Makefile in your main Makefile.am and not use recursive automake for that subdirectory:

LIBRARIES = modules/libfoo/libfoo.a

modules_libfoo_libfoo_a_SOURCES = modules/libfoo/src/a.c # ...

# and possibly some...
EXTRA_DIST = # ...