In the last post, we discussed the importance of good help. Today, the best practice we’re going to review (just joined us? have a look here) is provide a clean target. It’s pretty straightforward. As you change code (especially renaming source files), you’ll need to delete old files. You might as well automate the process.
I have seen builds that don’t use a clean target. But then generally these builds are relying on some other process, like nuking the entire checkout and starting again. It’s easier to have a clean target, honest.
You’d think that would be the end of it. Make a target called ‘clean’. Make it clobber some compiled code and generated artifacts. But while you go creating your new target, think about a couple of things:
– How many different files and directories do you need to delete? Ideally, it should be one directory. Life becomes very simple when you have a single tree to clean. Especially as you often end up making the opposite of a clean target to add directories back in.
– Did I say delete? If you have a single directory that the rest of the build depends on, check in into source control. You can often configure your VCS to ignore the contents (like cvsignore or svn:ignore) of the build directory. Then you can guarantee that it’s always there, but not have to worry about the built artifacts showing up when you go to commit.
Here’s one that I prepared earlier:
[…] file at the root of your project 3 of 15: Prefer a single buildfile 4 of 15: Provide good help 5 of 15: Provide a clean target 6 of 15: Manage dependencies with Ant 7 of 15: Define and reuse paths 8 of 15: Define proper target […]
At this time it appears like Expression Engine is the preferred blogging
platform out there right now. (from what I’ve read) Is that what you’re using on your blog?
Nope. WordPress.