Put it this way: I’m no novice and I’d use the IDE anytime over
build.exe.
With 10 binaries you can set up one or more projects, set up the
dependencies, done: double click on the .dsw or .sln and it
builds. No need for a release engineer. Everything’s included in
the dsw file, and you can tell your release engineer to invoke
it through a cl.exe command line for production builds. The dsp
files might as well be opaque, and what do you know, XML
documentation can be a real help if the programmer uses it
right!
In fact, with 10 binaries you might as well just compile them
every time, it takes less than 30 seconds on a modern machine.
Why bother with makefiles, sources files, and all the associated
paraphernalia ? Just write yourself a .bat file, say, “go.bat”,
type “go”, press enter, done. Takes less time than writing a
makefile or a sources file. But that’s not feasible for larger
projects, right ?
With the IDE, you can have multiple configurations through the
Config Manager. You can have different settings per
configuration. You can link projects through dependency chains.
You can subsume components from remote machines as an integral
part of your project, workspace or solution. You can compile and
test (even a driver!) from inside the IDE. You can set up your
paths on a workspace basis. You can add your own macros and
addins to the build process. You can change your compile and
link options through the IDE. You have automatic integration
with your source control system. You can add your own tools to
the environment by using VSIP. You have real-time, automatic,
on-the-spot, help.
The bigger my project gets, the more efficient it becomes to
build it with the IDE, because of the extensive configuration
management features included within. Also, if I use the IDE
right, it’s all interconnected and I don’t need to leave that
window: click the build button, click the debug button or press
F5, set breakpoints, single step, everything is done on the IDE.
No need to keep bouncing around between windows or bother about
whether software package x, y or z is installed or it is
correctly working: it’s all reachable from the IDE through
toolbars or through the tools menu. Writing and testing a
driver, mind you, becomes as easy as writing an application.
This is particularly important when you have multiple
directories: you can bury the directory structure inside the
structure of your workspace or of your solution, and you can use
the IDE browser to your advantage. Moreover, not to open another
can of worms, you can drive much of your development through the
Class view, no more need to bother about files either.
And again, hey, if you’re addicted to build.exe, just include it
as a post-build step. It’s that easy!
Alberto.
----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, May 10, 2005 8:47 AM
Subject: Re: [ntdev] DDKBUILD Update
> With MSVC 6 builds, the project containing 10 binaries
> require a dedicated
> position of the build engineer.
> Not so with BUILD.
>
> Building from IDE gives no advantages, except being more
> comprehendable for
> novices who are eager to build the 1-message-box demo apps.
> All really serious
> software - from the Windows kernel/core OS to all major open
> source titles - is
> built from the command line.
>
> That’s why MS moved to MSBuild, and uses it also as an
> underlying build
> engine in modern MSVCs. At least no more idiotic DSP files,
> XML files with
> documented syntax instead. You can, for instance, copy-paste
> the parts of them.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Alberto Moreira”
> To: “Windows System Software Devs Interest List”
>
> Sent: Tuesday, May 10, 2005 6:57 AM
> Subject: Re: [ntdev] DDKBUILD Update
>
>
>> After years of working with projects having hundreds of
>> thousands of lines of code, I’d use MSVC.NET pronto and
>> presto.
>> All the required functionality is there, from the
>> Configuration
>> Manager to the Macro Generator and Addin processor. Worse
>> comes
>> to worse, you can easily implement a build button (through an
>> Addin) to revert to the dark ages, if that’s what you really
>> feel like!
>>
>> Alberto.
>>
>> ----- Original Message -----
>> From: “Maxim S. Shatskih”
>> To: “Windows System Software Devs Interest List”
>>
>> Sent: Monday, May 09, 2005 6:29 PM
>> Subject: Re: [ntdev] DDKBUILD Update
>>
>>
>> > With such a project complexity, I would move to BUILD
>> > and
>> > command-line
>> > builds.
>> >
>> > Maxim Shatskih, Windows DDK MVP
>> > StorageCraft Corporation
>> > xxxxx@storagecraft.com
>> > http://www.storagecraft.com
>> >
>> > ----- Original Message -----
>> > From: “Loren Wilton”
>> > To: “Windows System Software Devs Interest List”
>> >
>> > Sent: Monday, May 09, 2005 12:15 PM
>> > Subject: Re: [ntdev] DDKBUILD Update
>> >
>> >
>> >> > The way I deal with this is to use a front end that sets
>> >> > the various
>> >> > environment variables used by visual studio. So for any
>> >> > given instance of
>> >> > visual studio there is one set of ‘global’ environment
>> >> > variables.
>> >>
>> >> Somewhat off topic, but your post reminded me: Anyone
>> >> know
>> >> of a good (or at
>> >> least reasonably clean and sane) way to get visual studio
>> >> to
>> >> deal with
>> >> multiple environments at once?
>> >>
>> >> We’ve got a UM project that consists of 20-30 individual
>> >> apps, dlls, static
>> >> libraries, etc. All this witches brew will build with a
>> >> single click of the
>> >> button in VS.
>> >>
>> >> There are also about 25 variations on exactly what it will
>> >> build, which you
>> >> select from the build type dropdown. All this works well
>> >> enough, except
>> >> that some are for x86, some are for ia64, and some are for
>> >> x8664. So you
>> >> have to have three copies of vs open, and somehow remember
>> >> which is which,
>> >> and only select the right build types in each one, or you
>> >> get
>> >> one whole pile
>> >> of bogus warnings and syntax errors from having the wrong
>> >> compilers and
>> >> linkers for the selected build environment.
>> >>
>> >> Since you have to build and test for all three
>> >> environments
>> >> after any source
>> >> change, this is a bloody pain.
>> >>
>> >> Can anyone think of a clever way to be able to set all of
>> >> the
>> >> tool and
>> >> include paths correctly when you select a build type from
>> >> inside VS? Keep
>> >> in mind that they will probably be different on every
>> >> developer’s machine
>> >> (and there are about 50 developers), and will certainly be
>> >> different in the
>> >> main build vmware machine environments.
>> >>
>> >> Thanks,
>> >> Loren
>> >>
>> >>
>> >> —
>> >> Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >>
>> >> You are currently subscribed to ntdev as:
>> >> xxxxx@storagecraft.com
>> >> To unsubscribe send a blank email to
>> >> xxxxx@lists.osr.com
>> >
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > You are currently subscribed to ntdev as: xxxxx@ieee.org
>> > To unsubscribe send a blank email to
>> > xxxxx@lists.osr.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as:
>> xxxxx@storagecraft.com
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com