Hi everybody interested in this topic,
> -----Urspr=FCngliche Nachricht-----
> Von: Christopher Sean Morrison=20
> Gesendet: Donnerstag, 16. Juni 2005 22:16
> I) MS Windows:
> Why are the (msdev.exe generated) files *.dsw, *.ncb=20
> and *.opt contained in the CVS repository?
> Those files, which are located in several of the core library=20
> and application directories, were the former msvc project=20
> build files from the initial Windows port. They used to=20
> build the core components of the port including libbu, libbn,=20
> librt, liboptical, rt, mged, asc2g, nirt and maybe a couple=20
> others. They are VC6 build files, though I wouldn't be=20
> surprised if they needed some modification to produce correct=20
> builds again. They could and probably should be removed if=20
> they don't work.
The *.ncb and *.opt contains user specific information:
I recommend removing them from the CVS repository.
I recommend to remove the *.dsw files too, because they aren't useful =
now. Msdev.exe generates these files if it was started with the *.dsp =
file. In contrast, a workspace containing all MS Visual Studio projects =
would be of some use. This could be placed in the root directory =
> Ideally, we should only be maintaining one build environment=20
> or having a tight coupling with developers that prefer=20
> alternate build systems (e.g. if someone wanted to maintain=20
> DevC++ project files). The existing GBS-based build=20
> environment (autoconf/automake/libtool) are currently the=20
> "official" build infrastructure. It would be nice if we=20
> could make a Windows build system that simply utilizes that=20
> same build infrastructure so that it is _always_ in sync=20
> without requiring one of the Windows developers to update the=20
> Studio project file(s) to get things working again every time=20
> a file or directory is added/moved/removed/etc. There are a=20
> variety of ways this should be possible.
This is a broad subject.
Maintaining only one build environment means to have a limited =
portability. The classic way to solve this is to have scripts on the CVS =
server. If you check in a "master file" (e.g. source file list of a =
library) a script generates the corresponding Makefile.am, *.dsp etc. =
files. This way, you could support some other IDE specific project files =