| Home | Press | Mailing Lists | Documentation | Screenshots | People | SourceForge | Downloads |
| Home
| Press | Mailing
Lists | Documentation | Screenshots
| People | SourceForge
| Downloads
|
by Robin Rowe 12/4/05
We use portable POSIX calls instead of platform APIs. You can't tell from looking at our code that it builds on Windows. It looks like typical BSD/Linux code. Our application code never calls <windows.h> or any other Microsoft Windows header file. Windows apps include <unistd.h>, the same as unix apps do. Using #ifdef WIN32 blocks to do platform-specific magic is generally a no-no in CinePaint code.
So how is it that POSIX code compiles on Windows? Inside libunistd is the magic to make code written with portable POSIX APIs and header file names build without complaint under Windows. Of course, only on Windows do we need to use libunistd. Other platforms already support POSIX portably.
Each developer is expected to verify that his code builds clean before checking in. You should always be able to build from what's checked into CVS. Before you can check-in you must first CVS update to bring in any changes others have checked in. Next do a test build, after update, just to make sure nobody's changes broke your code. Then check-in. The next time somebody goes to check-in on another platform they'll build with your changes. It'll get caught if anyone does something non-portable. By following our rules of using portable POSIX design, any breakage should be easily corrected.
Don't forget to add new files to CVS before doing a check-in. Forgetting this step is a common way for CVS to get out of sync.
TortoiseCVS seems better than WinCVS. Either can be used of course, but I've found TortoiseCVS easier to get to work. TortoiseCVS is closely integrated with Windows context menus and more intuitive to use. WinCVS seems to make at-random changes to the GUI from version to version that are annoying and not intuitive.
Download from http://www.sourceforge.net/projects/tortoisecvs/. Run self-installer.
Do this first, even if you plan to configure for CVS write access. It can save you time and aggravation.
Here's what CinePaint looks like after being checked-out:
Note that cinepaint-project is the directory created by the check-out. I created the directory named cvs and dragged cinepaint-project there after check-out. I did that simply because I like to organize my directories that way. It doesn't matter where you place cinepaint-project after you check it out the first time. You could put it somewhere else.
The green-checked folders are up-to-date in CVS. The blue-question folders are not checked into CVS. That's stuff I'm working on but is too messy to check in yet. The cinepaint-project-next folder is also not part of CVS, but is a folder I created to hold code I'm considering for later. This is how I organize my work as a developer. When you check-out you'll only get the green folders. As you change files they'll turn orange so you know they're newer than what's in CVS.
The cinepaint folder contains the legacy Film Gimp version of CinePaint. The new development version, called Glasgow, is in the glasgow folder. The rest should be self-evident. Although it's pretty obvious where they are when you browse the tree, if you have trouble finding the Visual C++ project files for any component you can always do a search on "*.sin".
Note that all the supporting third-party libs for Glasgow are in our CVS. These libs are all modified (improved) in various ways from the standard versions you can download from the library providers. In particular, the VC++ project files for these components are hooked correctly to Glasgow. If you're a Windows developer you need to use our versions of these libs.
Everything should build when you do a check-out. Although it inevitably happens sometimes, CinePaint CVS is never deliberately in a broken state. Please report any breakage to the CinePaint developers list.
If you have a SourceForge account name (you can easily create one) and are approved by the project leader as a developer, you can have write access to CinePaint CVS.
In another directory location aside from your pserver download, do another check-out. We're going to change the check-out settings. We're doing this to the side because you're going to interrupt this check-out and delete the files. The point of this second check-out is just to configure and test TortoiseCVS for write access. Once configured, you can use the write settings on the files you downloaded with pserver. You don't need to download the files a second time.
In the check-out dialog, set your settings to match this. Of course, you'll replace robinrowe with your SF user name.
If all goes well, you now have write access. You will have to enter your password a lot, which can become annoying if you do a lot of commits.
To do....