[PATCH phosphor-host-ipmid] Initial autotools support

[Stewart Smith]

Patrick Williams <patrick at stwcx.xyz> writes:
>> There's also the odd thing at the moment for host-ipmid where there's a
>> shared library that depends on symbols in the binary
>
> The shared libraries are plugins for host-ipmid.  We happen to be
> providing a set of common plugins but those can be overridden by a
> particular machine.  We also provide a set of openpower specific plugins
> for the parts of IPMI that are not specified (OEM commands) and those
> are in another package.

I was beginning to suspect that was the case, I only fairly late got
anything to individually compile (and didn't *really* look at source to
see what it was actually doing, and it turns out I slightly misread the
custom makefiles)

For a plugin case, we should really have the plugins only export 1 or 2
symbols (e.g. plugin_init, plugin_exit) too.

There's libltdl that does a bunch of the management/searching things for
you as well, including multiple search paths and I think even support
for building things in statically - as well as filters for validating
plugins. I *think* it has support for statically linking in some plugins
too... but it's been a few years since I even tried that.

> We should have a discussion on the call about autotools vs (...).  The US
> side of the team has zero experience with autotools and so it was easier
> to just write some simple makefiles to get started.

It's not too hard, and ends up being much shorter than custom makefiles,
and gets you things like correct header dependency tracking, a 'make
dist' target, a parallel test runner, detection of compiler flags and
build environment.

> I don't consider autotools to be the "defacto standard" since cmake is
> also pretty popular.

Cmake is *very* dependant on having cmake versions match between
platforms you're developing on and platform you build on - which tends
to mean everybody-gets-to-use-some-ancient-RHEL - or you have to dictate
to build teams what extra packages they're installing.

autotools on the other hand is designed so that you don't have to have
autotools packages installed at all on the machine you're building on,
you just need some level of agreement as to the versions on the machines
you're *developing* on.

The only real CMake advantage I've seen is that it'll build VisualStudio
project files so you can use a native toolchain on Windows.

>From an Ubuntu Wily system, it seems that cmake is used to build about
10% of source packages - autotools is probably around 4x that (it's a bit hard
to tell as all the dependencies for an autotools built package are
generally part of the assumed build dependencies).