Maxim S. Shatskih wrote:
> build commands are using ‘ddkbuild -W7XP checked’ for debug mode and ‘ddkbuild -W7XP free’
> for release mode
I just don’t understand why this is worth the time spent.
…
And, MSVC’s project mgmt is just plain inferior to SOURCES. The files are more complex, hard to comprehend by human, hard to diff in the source control, hard to copy-paste from another successful project.
I have to dispute this, for several reasons. It seems to me that your
objections are a result of unfamiliarity, rather than objective
comparison. Really, it is inaccurate to call SOURCES a “project
management” tool. It handles one build project, in one directory.
That’s not project management.
The vcxproj format is certainly more wordy than SOURCES, but it is
vastly more flexible, much more powerful, and obviously more completely
specified. I almost never go into the VS IDE, but I have now become
just as adept at manipulating vcxproj files from vim as I was at
manipulating SOURCES. You have the full power of C# available to you
for string manipulation, something that SOURCES makes virtually
impossible. I far prefer the vcxproj style now.
I have a couple of Python scripts that make some tasks easier. One will
generate a new GUID for a project. That in itself makes the
cut-and-paste task trivial. Copy, set new GUID, edit project name, set
source files, off you go. I have another that will create a .sln file
from an arbitrary set of .vcxprojs, so I can do multiple builds at
once. I have another that does a property sort, to gather the common
settings as much as possible. For example, instead of repeating all of
the settings 12 times (Win 7 Debug 32, Win 7 Release 32, Win 7 Debug 64,
Win 7 Release 64, Win 8 Debug 32, etc.), it collects a “Win 7” section,
a “Win 8.1” section, a “Debug” section, a “Release” section, a “32”
section, and a “64” section. Msbuild handles that just fine, and it’s
much easier to maintain by hand. It’s true that editing the properties
in the IDE will undo my collection, but I can put it all back.
Also, I’ve heard that minor change to build options in the MSVC GUI boxes can rearrange the project file totally to the state where diff is not possible.
In general, this is not the case. The IDE writes the properties in the
same order each time. There are some large operations you can do that
have a global effect, but when you’re making big changes, you have to
expect issues.
One of the tools I haven’t written yet is an XML diff. Since whitespace
is generally insignificant, one could do a much more intelligent job
than just straight character-by-character comparison.
Also, I don’t think !INCLUDE is supported in these files, which makes them even more primitive.
Of course it does. It’s used in virtually every project:
It’s now quite common for a development group to set up a “library” of
targets and options and store that in a local properties file, then
that into the project.
> Most serious software titles do not use GUI-generated build scripts, both in GNU world (autoconf, automake, CMake) and in MS’s world (MS’s internal build system called Razzle, of which BUILD+SOURCES is a subset).
Vcxproj tools do not have to be generated by the GUI. Also, many Gnu
tools are built with Eclipse, which goes generate the build scripts for you.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.