[PATCH modular] Add hooks to run a static analysis tool.

[Gaetan Nadon]

On Wed, 2010-12-22 at 00:35 -0500, Trevor Woerner wrote:

> On Wed, Dec 22, 2010 at 12:19 AM, Peter Hutterer
> <peter.hutterer at who-t.net> 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



> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101222/075c0ade/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101222/075c0ade/attachment.pgp>