<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0">
</HEAD>
<BODY>
On Wed, 2010-12-22 at 00:35 -0500, Trevor Woerner wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Wed, Dec 22, 2010 at 12:19 AM, Peter Hutterer
<<A HREF="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</A>> wrote:
> why not make --cmd to perform arbitrary commands instead of limiting it
> to git and make? Was there a discussion on this before? I just went
> through my email archive and only found ones that focused on git and
> make, not on just running an arbitrary command.
For my first iteration of this patch I had started by trying to add
another allowed command to --cmd but it didn't work; it got too messy.
--cmd doesn't allow any arbitrary command (it only allows 'git',
'make', and 'gmake') because the timing of when to run a git command
is different than the timing of when to run a make (or gmake) command.
If the user wants to run a git command the script will 'cd' into the
source directory and then can run the git command and move on to the
next module/component (without building). If the user wants to specify
an arbitrary make command the script switches to the source directory,
optionally runs the -p option, optionally switches to a build
directory (which is different than the source directory), optionally
configures the module/component, and then runs the arbitrary make
command.
In other words, the --cmd option has to know whether the arbitrary
command is a git command (in which case it is run at one point) or a
make command (so it is run at a different point in the build). If
--cmd allowed any arbitrary command to be used the build.sh script
would have no idea when to run it.
When I first tried to wedge the static analysis into --cmd it was
messy because the static analysis option requires the user to specify
where to place the reports (I think it makes sense to place them
somewhere outside of the PREFIX directory because otherwise 'make
clean' operations wouldn't know to clean them up, causing distchecks
and whatnot to fail). Plus I tried to make this option generic enough
to run any static analysis tool, which would require the user to
specify options to that other tool... all of which didn't fit into
--cmd's git or make assumptions.
</PRE>
</BLOCKQUOTE>
<BR>
I had anticipated the limits of adding features that are not strictly build related.<BR>
Aside from the difficulties Trevor mentioned, there is a danger of feature bloat.<BR>
<BR>
An alternate design is to add new scripts for new features. The main show stopper<BR>
has always been the duplication of modules names (recall git_xorg.sh and<BR>
build_from_traballs.sh). This is no longer a problem now that we can export<BR>
a list of modules from build.sh using the -L option.<BR>
<BR>
This is a powerful model, add as many scripts as you want for code policy check,<BR>
code metrics, statistics, you name it.
<BLOCKQUOTE>
<PRE>
build.sh -L > modlist.txt
newScript.sh --modfile modlist.txt
</PRE>
</BLOCKQUOTE>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
_______________________________________________
<A HREF="mailto:xorg-devel@lists.x.org">xorg-devel@lists.x.org</A>: X.Org development
Archives: <A HREF="http://lists.x.org/archives/xorg-devel">http://lists.x.org/archives/xorg-devel</A>
Info: <A HREF="http://lists.x.org/mailman/listinfo/xorg-devel">http://lists.x.org/mailman/listinfo/xorg-devel</A>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>