[Bf-committers] CVS, Make & MSVC

[bf-committers@blender.org]

On Tue, Oct 22, 2002 at 11:18:42AM +0200, Ton Roosendaal wrote:
> - we definitely want to support MSVC project files!
> - we're not the first open source project out there with this problem, 
> there *has* to be a little tool to turn Makefiles into project files?

As a Makefile is much more powerful than an MSVC project file, this
will be in general impossible. Simple example: I have a project consisting
of multiple libraries, compiled in both release and debug mode. It is
impossible in an MSVC project file to specify that the release version of
the EXE needs to be compiled against the debug version of one of the
libraries. (Even though there might be a workaround for this particular
example, the fact is that Makefiles are less structured and more powerful
than project files, making a lossless conversion from Makefile to project
file impossible in general.)

> - An alternative is:
> Is it possible to 'mark CVS dirty' or so, meaning that when someone 
> commits a change in projectfiles or makefiles, he also sends a (well 
> documented!) message to CVS marking it "MAKE_NEEDS_UPDATE" or 
> "MSVC_NEEDS_UPDATE". Someone else then can fix it, and mark CVS clean 
> again.
> This requires a discipline; the Unix guys never commit into a 
> "MAKE_NEEDS_UPDATE" CVS, but agree to fix it first. The Windows guys 
> never commit into a "MSVC_NEEDS_UPDATE" CVS, but fix that first as well.
> Also: a strict rule is that you never commit BEFORE having updated to 
> the latest CVS status, and compiled & tested that version.

These "strict rules" can be automatically enforced by the computer.
There are systems like aegis (aegis.sourceforge.net) designed to do
exactly this - to enforce a set of rules before check-in is allowed.
Furthermore aegis requires that software pass its own tests before
being allowed to be checked in. The problem with aegis is that it
raises human administrative overhead for the project: there have to
be "reviewers" who "review code" before aegis allows it to be
checked in, and there have to be "integrators" who integrate and
build each pending each change into a newly-checked-out directory
before the change is accepted.

I personally use aegis for all of my projects. However, I know from
experience that many people HATE the strict process that aegis
imposes. If you are committed to enforcing a process-oriented
software development cycle, I strongly suggest taking a look at
aegis. Briefly, the software development "process" that aegis
strictly enforces is:

1. Code must compile in the developer's directory (via the "aebuild"
command, which calls a user-defined makefile.) Aegis prevents further
progress until this is satisfied.
2. Code must run and pass its own tests in the developer's directory.
A test is simply a shell script which returns "1" for pass or "0"
for fail. An example for Blender would be to call blender in batch
mode to render a picture, then runs "cmp" to compare the rendered
picture with the expected render; a difference is a fail, an identical
render is a pass. The tests can be empty to bypass testing, but making
a built-in regression test suite is a good idea because then these bugs
never show up again, because aegis does not allow the developer to proceed
until the software passes its own tests.
3. The developer must run a diff command in the development directory
to generate a list of differing files in the development directory.
This encourages developers to look a second time at everything they have
changed before thinking that they are done.
4. The developer runs "aede" to end development. At this point the changeset
gets set in a "review" state.
5. A human reviewer must review the change, by looking at the code changes
submitted (there are aegis commands to extract these changes automatically).
The reviewer either lets the change pass further if it is okay, or
fails the change with a reason for failure (doesn't work, dangerous
change, etc), at which point it gets sent back to the developer.
6. After it passes code review, the changeset goes into "integration"
state.
7. At this point, a human integrator must rebuild the change in a new,
freshly-checked-out directory. (Aegis creates this new directory
automatically) The build must compile successfully and pass its own
tests successfully. If the build in the fresh directory fails, or if
the program does not pass its own tests, the integration fails and it
gets sent back to the developer. If it passes, then the changes are
commited permanently to the repository.

So aegis enforces a strict develop-test-diff-review-integrate code cycle.
I love it - some hate it.

The Linux kernel uses a proprietary software tool to do a very similar
thing to manage changesets to the Linux Kernel, but there have been
proposals to use aegis instead for Linux kernel development. (Aegis
by the way is GPL and has been around for almost 10 years; I have used
it for around 4 years)

As I understand it the Tinderbox system you used at NaN served a similar
purpose, but seemed less strict (it was possible to check in code which
did not compile - aegis does not allow this; more formally, aegis only
allows checkin of code for which the 'aebuild' command successfully
executes; by redefining aebuild to be nothing, you can of course trick
the system, which is not recommended).

I just wanted to mention this possibility of using strict tools to
enforce "discipline". "Manually enforced discipline" will fail sooner
or later in large multi-person software projects. Automatically
enforced "discipline" ensures a certain level of software quality,
but may slow down development and alienate more independent developers.

> 5. We need a disciplined set of CVS commit rules... :-)

Again, aegis (and perhaps other tools - Tinderbox?) can ensure compliance
with "rules". It all depends on if this level of discipline is acceptable
to all Blender developers. There is also the problem that 99% of open
source developers don't want a process model (the "just-let-me-write-to-
-CVS-I-don't-care-if-it-compiles" model of software development).
What do you guys think? Strict rule enforcement with aegis? Rule checking
but not necessarily enforcement with tools like Tinderbox? Or informal
rules with no checking?

-Norman

P.S. Ah, one last and important note - aegis only runs well on Unix-based
systems because it uses the permission system of the Unix filesystem
to prevent manual tampering with the baseline repository. This means that
to use an aegis system, all of those with write access to the repository
(in other words, all developers who are allowed to be "code integrators")
must be able to run aegis, and thus must be able to run a Unix-variant
(Linux works, FreeBSD probably as well, WinNT not at all). A Linux box
can test if a Windows version builds/runs by using Cygwin and a Samba
mount; the Linux aegis program uses ssh to run build commands on the Windows
box, and the Windows box accesses the aegis "sandbox" directory on the
Linux machine via a Samba mount.