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)/" @inc...@foo.pmyhh 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 valentin.da...@gmail.com
my.patch
Description: Binary data