-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Well i had a small look at the proposal i made last night, and it seems
that it is not possible to achieve what i was saying entirely from
autoconf by setting the command variables to be prefixed with the script
command. Reasons include:
1) It would be extremely difficult to obtain the target for the
operation, i.e. for the command CXX to give an output of the form: "C++
./blah/main.cpp" it would be difficult to find the filename. It may be
possible with sed, but that is just getting ugly.
2) It does not work nicely with libtool. When using libtool there will
be multiple occurrences of executing this script for a single command.
I.e. may be executing something like:
command_filter.sh "C++: file.blah" libtool --tag=CXX
--mode=compile
command_filter.sh g++ ....
So to achieve the functionality i desire i will need to modify automake.
I had a brief look at how i could do this manually for a small test
case. I ran configure for a small project i have created, and manually
edited the resulting Makefiles in a few places. I managed to achieve the
results i was after.
If i go ahead and try to update autoconf/automake in order to add this
as an optional feature that can be enabled by adding a specific macro to
the configure.ac file, will it be accepted?
My proposal is as follows:
A developer can choose to add this optional functionality of displaying
"clean" output to a projects build system. This would be achieved by
adding a macro to the configure.ac file that looks something like:
AM_CLEAN_OUTPUT([yes])
If this macro is NOT included in the configure.ac file, then all
Makefile.in files will remain exactly as they are now (I am assuming
that automake parses the configure.ac file as well as the Makefile.am
files but could be wrong on this). If however it is provided in the
configure.ac file (With a value of yes or no) then the Makefile.in files
will be modified to prefix every command with something like:
$AM_COMMAND_FILTER "C++: [EMAIL PROTECTED]" $(CC) ....
The autoconf macro would create a subst variable for AM_COMMAND_FILTER
that includes the full path to a script. The script executed can be one of:
filter_command.sh:
Runs a command with given arguments piping the stdout of the command to
/dev/null (May think about piping to a temporary file later). Before it
executes the command the script will display a description message which
is a simple summary of the command being executed like: "C++:
some/path/file.cpp". If the command returns with an error status, then
the script will display the command line that was executed. The script
will then exit with the status that the command exited with.
execute_command.sh:
Runs a command with given arguments. It does not redirect stdout or
stderr anywhere but just executes the command. When the command exits
then the script will exit with the status that the command exited with.
The purpose of this script is to provide a single interface for use in
the Makefiles.
Both the above scripts have the same usage:
./filter_command.sh <description> <command> args...
The macro described above AM_CLEAN_OUTPUT([yes]) would allow the user to
override the clean output by specifying a --with-clean-am-output or
- --without-clean-am-output. The configure script would then export the
AM_COMMAND_FILTER variable with the full path to filter_command.sh if
the clean output is enabled, or to the execute_command.sh script if it
is disabled.
These two scripts would be located in the directory specified by the
AC_CONFIG_AUX_DIR macro.
Thinking about the size overhead for the Makefile.in file that this
would create, it would require an extra variable exported for each
Makefile.in that contains the full path to the script to execute. In
addition to this, each command like executing the CXX command, or
executing libtool etc would have a prefix. There will be no additional
targets etc, but each target will be a little larger but i think that
the cost would be negligible and if it was a problem, then the developer
does not need to use this feature.
One other thing i noticed is that doing this still requires that i
execute make -s That is not really a problem, but does anyone know of a
way of making it so that the -s flag does not need to be specified if i
use the above approach.
If anyone has comments or suggestions (Remember that i have no
experience yet with developing automake) i would greatly appreciate it.
Thanks,
Brendon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFETXZELSWCuZeiyS0RAoobAJ9vsRISvC8kW4kO7vl2J4r/NxM9BQCfaNnR
bvYKgTcnICGQG+Zll+dZSgk=
=r91c
-----END PGP SIGNATURE-----
