0

I am writing a small tool in c++. It is actually more of a framework that is open to customization. It has the following directory structure (simplified example).

src/  
   main/myexec          # linked to libapple.so
   apple/  
        coder/libapple.so  
        john/libapple.so  
          .  
          .  
        james/libapple.so

Here, the directory "coder" is a generic dummy, with some example code to generate libapple.so. Different users can checkout this tool, create directories of their own, copy the template code from "coder" and customize as they wish. Depending on the configure option (indicating the user), the respective libapple.so needs to be generated.

As I mentioned, this is a simplified example. It is not a matter of generic programming, inheritance etc. In fact, similar to the "apple" folder there are others like "scripts", "docs", "configs" etc each having similar user specific folders. Also, the tool will be maintained at a single repository location to allow me to support & maintain all the code that is not specific to user. As a policy, users are expected to modify and check-in only the contents of their folders.

The problem I am facing is with "configure.ac". I do not want to use "AC_ARG_WITH" option as it would require each new user to edit configure.ac. Also for each user the AC_CONFIG_FILE entries would be exactly the same except for his folder name. I tried using "--enable-user=User" and then AC_SUBST(USERDIR), which also helps in setting "SUBDIRS = @USERDIR@" in Makefile.am. Everything looks good except for the fact that "Makefile.in" is not getting created under the user folder when I specify "AC_CONFIG_FILE = ([apple/${USERDIR}/Makefile])".

Please advice how to overcome this issue. In the worst case I may end up in creating softlinks :(

programmist
  • 564
  • 1
  • 7
  • 24
  • The error message on running configure is "config.status: error: cannot find input file: `apple/john/Makefile.in' – programmist Oct 25 '13 at 16:06
  • I would recommend using a distributed version control system instead of this scheme. Don't fight your tools. – ptomato Oct 26 '13 at 03:10
  • @ptomato, In a previous incident, distributed version control ended up in completely strange forks (teams customized even the main code on their own). Tracking and maintenance became difficult. This is an unofficial tool for internal use, for 30 to 40 teams each with their own customization requirements. My intention is to provide a combination of stable core (which I maintain) and flexible actions (for each team). Dynamic path is the only blocking issue now. Tools should not be too restrictive. For example, read arguments on wild cards in makefiles. Can auto tools help delete my pointers too? – programmist Oct 26 '13 at 04:11
  • I feel this way because, what I am asking for is not such a major thing. Variable substitution is valid at other areas of configure.ac, but not in AC_COFIG_FILE. The syntax lacks consistency in that regard. – programmist Oct 26 '13 at 04:20

2 Answers2

0

After one full day of scratching my head, following is the solution that I have come up with.

Create a file "project_makefiles.m4.in" like this

AC_CONFIG_FILES([ apple/USERDIR/Makefile ]

Add the below to configure.ac

m4_include([project_makefiles.m4])

Create a wrapper script like "build.sh" which will create "project_makefiles.m4" from "project_makefiles.m4.in" by replacing "USERDIR". This is done before the automake.

programmist
  • 564
  • 1
  • 7
  • 24
0

TL;DR Call automake on $USERDIR/Makefile in configure.ac, so that Makefile.in is created.

I know this is old, but it took quite a while to figure out and I'm hoping to save others the time. My use-case was similar, I needed to conditionally add entries to AC_CONFIG_FILES([..]) depending on arguments passed to ./configure.

The main problem is that configure.ac doesn't create Makefile.in from Makefile.am. automake does this (it is called when you run autoreconf). automake reads configure.ac to find the missing Makefile.in files, and creates them. It of course doesn't know how to handle a shell variable in AC_CONFIG_FILES.

My solution was to call automake within configure.ac, when a --with-docs argument was passed.

configure.ac

AC_ARG_WITH(
    [docs],
    AS_HELP_STRING([--with-docs=<path-to-docs-dir>], [Specify Path to docs]),
    [
        docs_path=$withval
        automake $withval/Makefile
        docs_files="$withval/Makefile"
    ],
    [
        docs_files=
        docs_path=
    ])
AC_SUBST([DOCS_PATH], $docs_path)

AC_CONFIG_FILES([other/hard-coded/files $d3_docs_files])

Main Makefile.am

# This may be empty depending on options passed to ./configure
SUBDIRS = @DOCS_PATH@

Also, if your path-to-build happens to not be a subdir of the main Makefile (mine was ../docs), then add this to the "subdir" makefile, to fix relative path issues.

docs Makefile.am

# Work around for SUBDIR=../docs (or other non-subdir relative path)
top_builddir=$(abs_top_builddir)
top_srcdir=$(abs_top_srcdir)
jkggins
  • 1
  • 1