'".am.in" ? Is it okay to write ".in" without generating it?

Simply put, I ran upon a "buildconf.py.am.in" file inside the project we're developing at work. Not really expert in autotools (I had to learn them for this job), this seems quite strange to me. Inside there's two VAR=@VAR@ and two VAR=[@]VAR[@].

How could there be an ".am.in" ? To me, this means that we write an .in to generates a .am that will be used to generate another .in (or .py, maybe). Does it look "legit" or should it be "fixed" ? Thus after the configure step, I do have a "buildconf.py.am", which is used during make process to generate a .py. It contains the following:

do_subst = sed  -e 's,\[@\]APP_VARDIR\[@\],$(localstatedir)/app/,g' \
    -e 's,\[@\]APP_LOGDIR\[@\],$(logdir),g'

buildconf.py: buildconf.py.am
    $(do_subst) < $(srcdir)/buildconf.py.am > buildconf.py

Is that "normal" or "acceptable" ? As I'm trying to consolidate the whole thing, since everything's become "tricky" and difficult to update, it looks like it's one of the huge amounts of fixes to me.

TY !

EDIT:

The script mostly defines paths for folders used by "plugins", thus needing things such as the datadir or the soft installdir. It also defines the folder structure to be used by those plugins so that they can be imported by the python code of the so-called plugins. Besides, those "plugins" actually are the server/routing layer of the application.

  • the buildconf.py.am.in file is not generated, but written by hand;
  • buildconf.py.am is declared amongst others in AC_CONFIG_FILES (how could it be ? It's supposed to tell "there must be a buildconf.py.am.in.am next to it, which will be used to generate a buildconf.py.am.in.in to then make a "buildoncf.py.am.in file... But all we want and get is buildconf.py);
  • running configure generates buildconf.py.am, setted variables are two booleans which tells if the mongoDB and web UI plugins are provided ;
  • make generates the final buildconf.py, to be imported where the constants it holds are needed. It is done at this time since it needs -I guess- variables expanded during the configure step.
autotools


Solution 1:[1]

I think this may just be a naming problem.

Usually .am files are included by Makefile.am and are expanded by automake, so for instance they are used to have per-directory definition of sources and targets while keeping the overall build non-recursive.

You can include files at the Makefile level so that the inclusion is executed by make instead, but calling them .am sounds wrong that way.

But in this case it's neither of those, this should probably rather be called .in.in (there are a few scripts that do something like that), but it feels a bit over the top. It probably makes just about the same amount of sense to do the processing once, by just applying all replacements during make phase.

I guess the likeliest case is is that somehow the original expansion was incorrect and it stratified, but not knowing the codebase it's hard to tell.

Solution 2:[2]

Looks like a three-step custom template like e.g. in Unity mono. There template first gets processed by autogen.sh: .am.in -> .am, then by automake .am -> .in and finally by configure script Makefile.in -> Makefile.

In autogen.sh it's:

if test x$has_ext_mod = xtrue; then
       cat mono/mini/Makefile.am.in ../mono-extensions/mono/mini/Makefile.am > mono/mini/Makefile.am
else
       cat mono/mini/Makefile.am.in > mono/mini/Makefile.am
fi

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Diego Elio Pettenò
Solution 2 user2745509

Related Questions