You're receiving this email because you requested to be a developer on the
IMA project at SourceForge.
First of all, I'd like to let everyone know that AMI is going to begin
working on the implementation and they are specifically looking to support
Linux. Adaptec had volunteered to work on the IMA implementation on a
'relaxed' schedule. Perhaps both companies can work together to get the
implementation done more quickly. Todd, can you comment on when you might
have people ready to work on IMA?
Second, I'd like for us to agree on some basics regarding the build
environment for IMA. Here's what I propose (taken almost entirely from
1. We standardize on GNU make as the build tool. The latest version is
3.80. I doubt we'll use anything that requires the latest version, but we
might as well state to use that version.
2. All make variables that can be externally set start with 'IMA_'.
3. That the make variable that identifies the platform that is being built
be named 'IMA_PLATFORM'.
4. That the value of the platform variable have the following form:
some examples: WINDOWS_IA32_MSVC, WINDOWS_IA64_MSVC, LINUX_IA32_GNU,
5. That the 'Makefile' itself exist in the root.
6. That a subdirectory 'mak' also exist in the root.
7. That the 'mak' subdirectory contain platform specific 'sub' makefiles
which get included in the master makefile depending upon the definition the
IMA_PLATFORM make variable.
(If we agree on these makefile conventions I'll upload some skeleton files
to the repository as examples).
8. That common code always be placed in the 'Common' subdirectory.
9. That ONLY platform specific code be placed into OS specific
10. The way the code is currently structured there should be no ifdef's the
common code. OS specific code should be encapsulated into the OS specific
classes/functions found in the OS directories.
One comment regarding the above proposal: if followed judiciously, adding
support for a platform should (ideally) result in NO changes to existing
files. Only the addition of new files.
Finally, I'd like for us to agree on some procedures regarding CVS. Right
now checking into CVS is not moderated and I'd like to keep it that way.
1. Never leave the HEAD so it cannot build. If you check in a source file
that depends on a change in a header file check in the header file too.
Don't break the build. Bugs are one thing, but not being able to compile or
link is something else.
2. Don't sandbag changes/additions. As you get changes or additions
completed CHECK THEM IN. Yes, this will result in more checkins than would
otherwise be necessary. That's preferable to 30 new files appearing one day
and every existing file being changed and a client not working any more.
Well, that's about it. Please let us know what you agree with, what you
disagree with, and what additions or changes you would like to see made.