[2/4] Add subdir-objects automake option

From: Andreas Rottmann <a.rottmann@gmx.at>

Having subdir-objects enabled is recommended by automake 1.14, to avoid
future incompatibilities.

However, adding that option breaks out-of-tree builds, and also seems to
break "make distclean" for in-tree builds. The reason is that
apparently, automake with subdir-objects enabled cannot cope with source
files in a different, non-child directory. To avoid that, we simply
compile the files referenced in this way into a static library in their
own source directory, and instead of referencing the source files, we
link against that library.

Besides making the build system a bit more future proof, this change
also potentially enhances build times, as it reduces the number of
compiler invocations, in exchange a slight increase of "ar" invocations.
---
 openbsc/configure.ac                   |  2 +-
 openbsc/src/gprs/Makefile.am           | 20 ++++++++++++--------
 openbsc/src/osmo-bsc_nat/Makefile.am   |  7 +++++--
 openbsc/tests/bsc-nat-trie/Makefile.am |  6 +++---
 openbsc/tests/bsc-nat/Makefile.am      | 11 +++--------
 openbsc/tests/bsc/Makefile.am          |  6 +++---
 openbsc/tests/gprs/Makefile.am         |  6 +++---
 openbsc/tests/smpp/Makefile.am         |  7 ++++---
 8 files changed, 34 insertions(+), 31 deletions(-)

> On 16 Jun 2015, at 23:23, Andreas Rottmann <mail@rotty.xx.vu> wrote:
> 
> From: Andreas Rottmann <a.rottmann@gmx.at>
> 
> Having subdir-objects enabled is recommended by automake 1.14, to avoid
> future incompatibilities.
> 
> However, adding that option breaks out-of-tree builds, and also seems to
> break "make distclean" for in-tree builds. The reason is that
> apparently, automake with subdir-objects enabled cannot cope with source
> files in a different, non-child directory. To avoid that, we simply
> compile the files referenced in this way into a static library in their
> own source directory, and instead of referencing the source files, we
> link against that library.
> 
> Besides making the build system a bit more future proof, this change
> also potentially enhances build times, as it reduces the number of
> compiler invocations, in exchange a slight increase of "ar" invocations.

That automake behavior is shameful. What would be the effort to get rid
off the recursive make?

On Wed, Jun 17, 2015 at 07:47:45AM +0200, Holger Freyther wrote:
> > On 16 Jun 2015, at 23:23, Andreas Rottmann <mail@rotty.xx.vu> wrote:
> > 
> > From: Andreas Rottmann <a.rottmann@gmx.at>
> > 
> > Having subdir-objects enabled is recommended by automake 1.14, to avoid
> > future incompatibilities.
> > 
> > However, adding that option breaks out-of-tree builds, and also seems to
> > break "make distclean" for in-tree builds. The reason is that
> > apparently, automake with subdir-objects enabled cannot cope with source
> > files in a different, non-child directory. To avoid that, we simply
> > compile the files referenced in this way into a static library in their
> > own source directory, and instead of referencing the source files, we
> > link against that library.
> > 
> > Besides making the build system a bit more future proof, this change
> > also potentially enhances build times, as it reduces the number of
> > compiler invocations, in exchange a slight increase of "ar" invocations.
> 
> That automake behavior is shameful. What would be the effort to get rid
> off the recursive make?

AFAIR there was a patch series a few years ago from Diego Elio Pettenò 
(flameeyes) that changed the build system behavior of several osmo* 
subprojects to use non recursive make. There were objections against 
them, so they were not merged.

Kind regards,
-Alex

> On 17 Jun 2015, at 10:04, Alexander Huemer <alexander.huemer@xx.vu> wrote:
> 
> 
> AFAIR there was a patch series a few years ago from Diego Elio Pettenò 
> (flameeyes) that changed the build system behavior of several osmo* 
> subprojects to use non recursive make. There were objections against 
> them, so they were not merged.

hehe, but we did merge parts of libosmocore? E.g. all test directories are
non-recursive there?

Hi!

On Wed, Jun 17, 2015 at 01:36:05PM +0200, Holger Freyther wrote:
> 
> > On 17 Jun 2015, at 10:04, Alexander Huemer <alexander.huemer@xx.vu> wrote:
> > 
> > 
> > AFAIR there was a patch series a few years ago from Diego Elio Pettenò 
> > (flameeyes) that changed the build system behavior of several osmo* 
> > subprojects to use non recursive make. There were objections against 
> > them, so they were not merged.
> 
> hehe, but we did merge parts of libosmocore? E.g. all test directories are
> non-recursive there?

The relevant commits with build system changes that were merged seem to 
be these:

7e007e0f87c4a06396ef46081ef1d69a4bdc11ae
build: avoid multi-level recursion for src/ directory.

d471a2192015440ec9b8c409268ba6433511f421
build: simplify headers management and remove recursion

ea0e1eca2bc32b531242a3b0a3c471e492a6f493
build: simplify test handling and speed up build.

I can dig up the unmerged ones from the old ML if that's of any value.

Kind regards,
-Alex

Hi!

On Wed, Jun 17, 2015 at 02:04:45PM +0200, Alexander Huemer wrote:
> On Wed, Jun 17, 2015 at 01:36:05PM +0200, Holger Freyther wrote:
> > 
> > > On 17 Jun 2015, at 10:04, Alexander Huemer <alexander.huemer@xx.vu> wrote:
> > > 
> > > 
> > > AFAIR there was a patch series a few years ago from Diego Elio Pettenò 
> > > (flameeyes) that changed the build system behavior of several osmo* 
> > > subprojects to use non recursive make. There were objections against 
> > > them, so they were not merged.
> > 
> > hehe, but we did merge parts of libosmocore? E.g. all test directories are
> > non-recursive there?
> 
> The relevant commits with build system changes that were merged seem to 
> be these:
> 
> 7e007e0f87c4a06396ef46081ef1d69a4bdc11ae
> build: avoid multi-level recursion for src/ directory.
> 
> d471a2192015440ec9b8c409268ba6433511f421
> build: simplify headers management and remove recursion
> 
> ea0e1eca2bc32b531242a3b0a3c471e492a6f493
> build: simplify test handling and speed up build.
> 
> I can dig up the unmerged ones from the old ML if that's of any value.

Actually, all patches from flameeyes for libosmocore were merged.

Here are the overall numbers. merged/sent with commit summary lines of 
the unmerged patches.

libosmocore 12/12

libosmo-abis 7/7

libosmo-dsp 3/5
build: flatten build to a single Makefile.am
build: avoid running unused checks

libosmo-sccp 0/7
mtp_pcap: mark structure as constant as well as static.
m2ua: remove unset talloc context.
build: flatten headers installation in include/Makefile.am
build: set automake options in configure.ac only.
build: simplify test build
m2ua: accept a constant parameter in m2ua_from_msg.
tests: remove warnings and make more data constant.

osmo-gmr 0/7
build: avoid recursing into include/ for non-installed headers.
build: simplify building by avoiding recursion in src/.
gmr1_rx: remove to variables set but not used
build: simplify documentation install.
build: remove unused test and get rid of libtool.
build: move automake options to configure.ac
gitignore: ignore src/gmr1_gen_mat as well.

sam7-util 2/2

Kind regards,
-Alex