[rt-devel] contributions helper
ssinyagin at yahoo.com
Sat Dec 21 19:35:37 EST 2002
Thanks for the good explanation. I think it must be put into
RT/FM, for the history.
--- Bruce Campbell <bruce_campbell at ripe.net> wrote:
> On Sat, 21 Dec 2002, Stanislav Sinyagin wrote:
> > I think it would be nice to integrate a small utility
> > into RT distribution which would help to install and
> > (probably) maintain the contribution add-ons.
> You need to be more precise, as there are a number of types of add-ons,
> all of which are somewhat different.
Actually, as I wrote yet only one add-on, and it's an executable script
which uses RT libraries, that type of add-ons was my main concern.
I think it's quite boring process: every time I update my script,
someone who uses it needs to edit those same line, like Perl location,
and RT paths.
Currently (2.1.x) configure.ac does variable substitution for all
files, including Makefile.in and lib/RT.pm.in. That's actually not
the way the autoconf manuals recommend.
They do recommend (as far as I believe) to use AC_CONFIG_FILES()
only for Makefiles and a small utility that would replace the variables
for the rest of the files. Then those makefiles would call this
utility for all their targets that need the substitution.
That's actually what I did in http://rrfw.sourceforge.net,
and it works fine.
In case of RT, this utility would be useful not only for RT installation
process, but also for contribution scripts.
As for the other types of contribs, that's nice that the new RT is more
adaptated for them. Still, it would be nice to rely on config variables
like $MasonLocalComponentRoot in the contrib installation process,
and make this as much automated as possible.
It only needs some standartization efforts, to force the contrib packages
to conform some requirements. And a small package management utility
would do the job of copying the files in the right places.
This would bring us many benefits, like:
-- harmless contribution packages that don't break the system
-- easier troubleshooting
-- easier way to determine what the heck is running on
the site that someone else installed before you
and so on.
I think I'll have some time during next few weeks for coding
parts of it, after I get the green light from the community.
Speaking of autoconf, and once my critics on installation process
is accepted, what about moving to Automake?
This would solve some issues, like distribution tarball generator
(now tarball includes both configure sources and the produced output),
dependencies check (configure would run automatically should it be needed),
and just because it's a nice product and a great deal of tasks is already
P.S. being on-call doesn't prohibit you a beer or two?
More information about the Rt-devel