On Wed, 2010-12-22 at 00:35 -0500, Trevor Woerner wrote: > On Wed, Dec 22, 2010 at 12:19 AM, Peter Hutterer > <[email protected]> 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.
I had anticipated the limits of adding features that are not strictly
build related.
Aside from the difficulties Trevor mentioned, there is a danger of
feature bloat.
An alternate design is to add new scripts for new features. The main
show stopper
has always been the duplication of modules names (recall git_xorg.sh and
build_from_traballs.sh). This is no longer a problem now that we can
export
a list of modules from build.sh using the -L option.
This is a powerful model, add as many scripts as you want for code
policy check,
code metrics, statistics, you name it.
build.sh -L > modlist.txt
newScript.sh --modfile modlist.txt
> _______________________________________________
> [email protected]: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
