Hi!
I'd like to know, how the Visual Studio project files are generated and
maintained.
I'm having a hard time coping with them, especially when they get updated.
(I don't have direct access to the SVN repository, I need top export the
project and copy it over to my development machine)
I always do:
1. switch the runtime DLL linkage from "static" to "dynamic"
2. create distinct names for the 32/64bit and release/debug output files
3. adapt the names of other output files(.lib, .pdb) as well, to match the
corresponding DLL
4. disable OpenMP, since I only work with the standard edition of Visual
Studio
5. enable some more optimizations in Release builds
6. Adapt client.cpp to load the right DLLs for the right builds.
Also, the current file structure is a bit weird from my point of view.
Are there any linux/unix/mac requirements that make the current structure
necessary?
I'm used to the following convention
Equalizer/
eq/ // header files
base/
client/
server/
etc.
src/ // source file
base/
client/
server/
etc..
lib/ (for executables this is often named
bin/)
EqualizerClient.dll
EqualizerClient.lib
EqualizerClientD.dll
EqualizerClientD.lib
EqualizerClient_x64.dll
EqualizerClient_x64.lib
EqualizerClientD_x64.dll
EqualizerClientD_x64.lib
etc.
build/ // obj files will go here
win32/ // platform
Release/ // configuration
Build/
X64/
Release/
Build/
examples/ // example projects and config files go here
doc/ // documentation
Redistribution will the just leave out the src and build directory and
your're done. By clearly separating debug/release and platform in the DLL
name, I can easily switch between them and all version happily live besides
each other.
Special needs for redistribution can be placed into an extra "deploy"
script which copies the redistributable files into the right place and zips
them. I find the prebuilt-event attached to _each_ single headerfile
cumbersome and error prone. Let deployment be e separate step, independent
of development.
Another suggestion is to unify EqualizerClient.dll and EqualizerServer.dll
into one. Both depend on each other anyway. And the code-responsibility of
both is sufficiently separated by namespaces.
One DLL less is one project file less, which means easier maintenance and
easier redistribution.
How's your opinion? Are there any Linux/Unix peculiarities I'm not aware of?
Thanks,
Mathias
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
