[p4] Build tool for Perforce builds & Dev Studio......

[Paul C. Pharr]

At 10:44 PM 6/14/2001 -0700, Jeff A. Bowles wrote:
>I wrote:
>>  many, many companies use MS Dev Studio
>>         project files and build using "msdev /make filename.prj"
>>         to build the projects (which is a mechanism I don't like)
>
>At 12:23 AM 6/15/2001 -0400, Paul C. Pharr wrote:
>>I'm interested in this statement & I'm wondering if you could expand on 
>>it a little. We are now deploying an auto-build system which test builds 
>>all submissions to our depot on both Mac and Windows. Since we use MSVC's 
>>project files for our main project on Windows, the auto-build system must 
>>reliably kick off DevStudio builds, and we were intending to use the 
>>msdev /make mechanism but after fighting with it, we were foiled at every 
>>turn. It seems wholly unreliable when called from popen in a python 
>>script - apparently related to the fact that msdev is not really a 
>>console application but behaves something like one when called with 
>>/make. . . .
>
>         Okay, here goes.
>
>         [Aside: your "popen" problems on Windows have to do with the
>         fact that the C library version of "popen" on Windows is broken.
>         The Python 1.5.2 executable on Windows inherits this problem,
>         and a "win32all" package downloadable from www.python.org
>         addresses this by providing its own popen/popen2/popen3/popen4
>         set of interfaces. Python 2.0 claims to deal with this appropriately
>         on Windows, but I'm not convinced that it behaves reasonably
>         on Windows/Me; I worked around a lousy "popen" on Windows/Me
>         in Python, yesterday, using "cmd > file 2> file2" and opening those
>         files to read the output. Yuck.]


I'm using Python 2.1 with win32all and neither popen nor popen2/3/4 will 
work with msdev, but they both work great with p4. From my admittedly 
limited experience in this respect, it looks like popen with Python 2.1 is 
far more challenged with GUI applications than traditional console tools. 
To be honest, I couldn't get exec or system to work reliably with msdev 
either. msdev would never find the project file passed on the command line 
no matter how I quoted it (or even after rearranging the location so I 
didn't need to pass any path info at all. the COM stuff works well enough, 
though.



>         I don't like "msdev /make" for the simple reason that it's using
>         a binary file that cannot easily be recreated or tracked, to 
> determine
>         every last thing about the build, compile flags, source files to 
> include,
>         and so on. Although you can tweak things to make it less unpleasant,
>         it's just nearly impossible to know that the REAL difference between
>         build A and build B is that the second was compiled with debugging
>         on and with this library substituted for that one.
>
>         And if you can't tell your QA folks what's different between this
>         handoff and the last one that you gave them, you should change
>         tools. Or positions.

While I certainly agree that msdev uses far too many cache files to store 
temporary information for the IDE - mostly debugging and browser related 
information - and these files can sometimes get out of sync and cause 
usability issues, the main project definition files (.dsp & .dsw) are all 
ASCII text as of MSVC version 5 & 6 that we use. While it's usually not the 
best practice to edit the text directly, it's rather readable when doing 
diffs to account for project changes. I certainly agree that the 
accountability of the build process is important, but this seems to be 
where we have the least problems with MSVC 6.

The Metrowerks IDE that we use on the Mac side seems to match your 
objections more closely because the .mcp files they use are binary and 
totally opaque. CodeWarrior 6 introduced the ability to export projects as 
XML, so you can get a diff if you really need it by manually exporting XML 
of the two project files in question and diffing the text. It would be 
really nice if they would allow a reasonable way to use the XML version by 
default so that could be the version submitted to Perforce

Is it the project and workspace files (.dsp & .dsw) that you object to or 
have you found other temporary files affecting the repeatability of msdev 
builds?


>         That said, the developers of "msdev /make" belong in their
>         own ring in Dante's Inferno. Errors sometimes come up in
>         dialog boxes that require mouse clicks to dismiss, which is
>         unforgivable in a batch build environment; it's tough to figure
>         out what was rebuilt and what wasn't, and really messy to
>         get it to do a full or an incremental rebuild that really does
>         what you asked for. Did I mention inconsistent use of full
>         or relative pathnames?

These types of things are my main objections to Dev Studio. There seems a 
complete lack of attention to minor things that really affect our ability 
to use it efficiently on a large project. MS believes that if there is even 
a bad way to do it via the GUI, then no further attention is necessary. 
Trying to get MS to change the tool is like pulling teeth. They are totally 
focused on how to make their tools more closely tied to .NET and other 
proprietary MS technology concepts.


>         I would use it as a stopgap measure while I figured out
>         how to either generate a MS Dev Studio project file from
>         a text-file template (with some sort of automation to build
>         to project file) or while I researched another build tool.
>
>         Maybe MS Dev Studio provides a nice IDE for the
>         developers, but it does NOT provide a nice build
>         tool for the build geeks.

It almost sounds like you are using MSVC 4.x. Have you looked at the newer 
versions over the last few years and how they handle project files? I'm not 
really defending the tools overall, because we certainly have some 
objections to the development priorities of Microsoft with MSVC, but I 
haven't had the kinds of problems you reference.

>         (Onions to those folks who want to respond with "but you
>         can just have MS Dev Studio create a makefile for you!".
>         Trust me. Those generated makefiles are bad.)
>
>         -Jeff Bowles
>         Perforce Consulting Partner
>         (but don't beat up Perforce for THESE opinions!)


Thanks for your comments!

Paul C. Pharr
CAD Software Manager
Nemetschek North America