User extensions

[Valentin David]

Dear Automake list,

I work with programming languages. It is very common to write small
compilers, parser generators, or other. When using my tools, it is
hard to convince my co-workers they should use the autotools when I
cannot do the proper extension of Automake. Other people end up
writing builders for Eclipse. I will never go to the dark side. And I
wish to provide the right developing tools for my users, e.g. an
extension to Automake. It is very easy to extend Autoconf for
instance. But not for Automake.

I realize, it is not often that people want to extend Automake. Most
of the time, fancy libraries are coming with their Autoconf files, and
the user is using the same compilers. Libraries do not need extension
in Automake. Compilers do.

To keep a patch set for Automake is not an option. It already
irritates the system administrators when I tell them that the versions
of the autotools are too old. Moreover, I cannot ask my co-workers to
install it by hand in another prefix.

You would surely ask me why I do not just write generic rules in a
makefile to be included anywhere I need to use my tool. This has
several problems.

The first problem I encounter, is the dependency files. My tools might
generate some. It is too much to ask a user to include by hand a
dependency file. If there are several objects to compile, then they
will just probably forget to include some. Also, you need to use
"-include" (which I wonder whether it is portable), or trick Automake
by using "@am__include@". The latter might be caught by the config
command from depout.m4, so you do not have to make one. Tell the users
why they cannot use just "include" instead...

Second problem, you cannot use the Automake variables to generate the
right files. The user needs to trick. Here is an example.

#INCDEP is subst to "include ./$(DEPDIR)/"
@address@hidden

EXTRA_DIST=foo.myhh
foo_SOURCES=foo.cc
nodist_foo_SOURCES=foo.hh

# This does not work, guess why.
foo-foo.o: foo.hh

# This one will work, but it is like killing a
# fly with the assault rifle, specially if you
# have several objects. Hope you have ccache.
$(foo_OBJECTS): foo.hh

So now, it is not obvious for the user why foo.myhh is not a source,
but an "extra", why foo.hh has to be set manually in the sources, and
you are happy when your user understands what "nodist_" means.

What I wanted the user to write was only:
foo_SOURCES=foo.cc foo.myhh

After all you can do it with Yacc or Lex, why not with my tools?

I propose a patch as attached.

* The lang_*_rewrite are added to the Language structure. The default
is lang_sub_obj. They do not return anymore the object extension
because the field 'output_extensions' already computes it.

* Compilers that generate source files might still generate dependency files.

* --libdir= can be called several times, the arguments can also have a
list of paths separated by a colon. Empty paths correspond to the
original libdir.

* For all libdir, all libdir/lang/*.pm are loaded. This happens right
after parsing the options.

The test tests/user_def_lang.test should show how the feature works.

I can understand that loading perl files is not really nice because
there easily can be problems of backward compatibility.

I am waiting for your comments.

Best regards,
-- 
Valentin David
address@hidden

my.patch
Description: Binary data