On 8. May 2009, at 15:42, Mathias Heyer wrote: > Hi! > > I’d like to know, how the Visual Studio project files are generated > and maintained.
Manually, either be editing them or in VS. > 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 This should be scriptable, since the .vcproj is just a XML file. > 6. Adapt client.cpp to load the right DLLs for the right builds. A simple patch should do the trick. > > 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? Partly historical reasons, partly personal preferences (see below). > > I’m used to the following convention [...] > Redistribution will the just leave out the src and build directory > and your’re done. Now everything you need is in the build directory, see also VS2005/ copyBuild.bat > 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. That's a Windows-ism I never fully grokked. If you use the same DLL name, you can simply switch between debug/release by setting your LD_LIBRARY_PATH. The different versions typically live in different directories. What's the benefit of naming DLL's differently? > 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. That stems from a previous build system I worked with, and found it's way into the VS projects through the Makefiles. It is debatable if it's needed in its current form. Not all header files are installed. The src/ directory also has internal headers, which are not distributed, e.g., for the net::Object change managers. The copy step allows and forces one to think which headers are to be installed publicly, and it's just a list in the Makefile. > Another suggestion is to unify EqualizerClient.dll and > EqualizerServer.dll into one. Both depend on each other anyway. Not true. The client DLL does not depend on the server dll. The separation forces us to keep this separation clean. The client DLL dlopen's the server DLL - but this is merely a convenience to run w/out a separate server process, not a dependency. > And the ciode-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? My statements above are simply to explain the current situation. I'm open to change certain things, but I'ld need to see a proposal on what to change exactly, and it would have to be done on all platforms consistently. Maybe other users have other opinions as well... Cheers, Stefan. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
