Fog Creek Software
Discussion Board




Build scripts: explicit or implicit?

I'm putting together some nant build scripts to improve our build process. One question which comes up every time a system like this is put together is to use explicit or implicit source file references.

In other words, should the csc (compile) task look like
<includes name="foo.cs" />
<includes name="bar.cs" />
Or
<includes name="*.cs"/>
Same with copy or any other task.

Advantages to explicit:
* Unintentional code doesn't sneak in. Or dissapear.
Advantages to implicit:
* Build files much easier to manage--usually doesn't require changing at all.

I'm tempted to start with an implicit list, to remove the load of yet another script to manage.

Any thoughts on this?

mb
Friday, September 05, 2003

Use work with ant (the java mother of all xant implementations) a lot. I usually work with implicit filesets and exclude specific files if necessary.

Janek.

Janek Schwarz
Friday, September 05, 2003

Maintaining a build script makes you THINK about the build before you do something that changes it, and thinking about the build is goodness!

I personally disklike the "implicit" approach and my team by and large does not use it.  Here are a few scenarios in no particular order:

1)  You have a file that contains too much stuff, so you check out bar.cs, move some of the code to foo.cs, and build.  Your build of *.cs goes just fine, so you check in bar.cs and break the build.  Oops, you forgot to add foo.cs to the source control system. 

If you have to edit the script to make it build on your machine, then that is a big reminder that you need to check in foo.cs as well to make the build work.

2) You have a buggy module which you wish to remove from the daily builds temporarily.  If you always compile *.cs then your only option is to delete the file and re-add it later.

3) You are working on a new feature in baz.cs and have baz.cs in an uncompilable state when suddenly a high-priority bug comes in -- foo.cs needs to be fixed right away.  But you can't build _at all_ if you are building *.cs, without moving baz.cs out of the directory where it belongs.

None of these are earth shattering, obviously.  But my point is that the pain of maintaining a build script is about the same as the pain caused by having an aggressive script that compiles everything it sees, whether you want it to or not.  Given the choice of these two pains, I'll take the easy, predictable pain of maintaining an explicit script.

Eric

Eric Lippert
Friday, September 05, 2003

None of these is earth shattering, and none of them need be problems, either.

"1)  You have a file that contains too much stuff, so you check out bar.cs, move some of the code to foo.cs, and build.  Your build of *.cs goes just fine, so you check in bar.cs and break the build.  Oops, you forgot to add foo.cs to the source control system."

Get Continuous Integration.

"2) You have a buggy module which you wish to remove from the daily builds temporarily.  If you always compile *.cs then your only option is to delete the file and re-add it later.

"3) You are working on a new feature in baz.cs and have baz.cs in an uncompilable state when suddenly a high-priority bug comes in -- foo.cs needs to be fixed right away.  But you can't build _at all_ if you are building *.cs, without moving baz.cs out of the directory where it belongs."

These are both the same problem, and ignore the fact that with NAnt, you not only have <includes>, but also <excludes>.

Brad Wilson (dotnetguy.techieswithcats.com)
Friday, September 05, 2003

Use implicit but always build from a pristine area (eg, a CVS workarea).  That way no unexpected surprises creep in.  At least, not in the form of "that was that DLL we blew away three months ago!"

van pelt
Friday, September 05, 2003

My vote's for whatever fits your mental model...  Usually it's compile({sourcefiles - exceptions}) rather than compile({file1,file2,...})

The reasoning is that while explicit avoids certain errors, human minds get tired and make mistakes if they don't let the computer do work for them.

But whatever works for you...

sammy
Friday, September 05, 2003

'implicit + clean workarea' is exactly my plan, good to hear others use it. it's also the main reason to use a csc rule instead of calling the project from the environment--you can't build a visual studio web project from a clean environment due to IIS config issues.

mb
Friday, September 05, 2003

I would also vote for the consensus of all - exceptions. If you have an explicit system, it becomes a major maintenance problem in its own right (I know - we used to have a system like that) so then you get problems where your code won't build not because of errors in the code, but because someone forgot to add foo.java to the explicit list.

Sure, implicit runs a risk that something will creep in unintentionally, but as other people have said, you can largely manage that by building from a clean area.

Just my $0.02.

Matt
Monday, September 08, 2003

*  Recent Topics

*  Fog Creek Home