[p4] encapsulation of third party software

[Jeremy Russell]

We have taken to breaking apart the .NET framework into component pieces and checking them instead of installing the whole thing (we support building 1.1 and 2.0 in the same buidl environment) (of course this also means you can't test on your dev/build box because the entire framewrok is not available). We do the same for the native compilers and such. We do not build using much of the Visual Studio tools straight out of the box. We break it apart and as we used to on UNIX - check in the libs and stuff from the SDK that we need and forget the rest. The only thing we do with the registry is to make sure that StrongName validation is always turned on (no delay signing). Of course we have to make sure we function with in the constricts of the licenses.
 
The registry is often a convenience, not a neccesity - don't make the mistake of thnking that you must have the registry settings available. I do get frustrated with the way Windows works sometimes, but all it takes is a bit of the creativeness that UNIX people are supposed to have and so rarely show on the Windows platform (I think they tend to get lazy because Windows tries to do everything for you unlike UNIX which just tries to give you a good framework so you can do what you think is best). The framework principals are in Windows as well, but with a really, horrible, terrible, really bad command line (you can't even call it a shell).
 
Something to keep in mind: Visual Studio is a development environment (IDE normally), not a build/release environment. Do not make the mistake of trying to force it into a normal configuration management mold for build infrastructure. Our Wiondows and completely MS build environment can be used by copying down a share or syncing a client view - I would say we don't make one registry write, but I can't. It turns out that when you run signtool.exe for Authenticode signing it registers CAPICOM - so I guess the tools themselves do that, but it still runs seamlessly. It takes a lot of work to get there, but no more so than when I was working in a LINUX shop and I had to get the build system to quit relying on system libraries.
 
-Jeremy


----- Original Message ----
From: "Weintraub, David" <david.weintraub at bofasecurities.com>
To: Monica Sanchez <msanchez at FreedomScientific.com>; perforce-user at perforce.com
Sent: Tuesday, October 3, 2006 2:00:33 PM
Subject: Re: [p4] encapsulation of third party software


Heck, if you figure it out -- let us know. I am building a new
CruiseControl server, and now am spending the entire day installing all
the friggin' packages. I hate Windows. I hate Bill Gates for coming up
with Windows. As we say in New Jersey. "If something bad would happened
to Mr. Gates, it would not make my heart unhappy."

What we do is put all the install packages (with instructions) into a
DevTools directory in Perforce, and all users are suppose to install
them into their PCs. If you are not using .NET, all the tools must be
installed in the same directories, so they're the same from machine to
machine. Otherwise, you have to depend upon the PATH variable which is
limited to 1024 characters. If you're using .NET, things are a bit
easier if you only use .NET compatible tools because .NET looks in the
Windows Registry to see where the DLLs actually lie instead of depending
upon the PATH variable.

As I said, the best we can do is some READMEs, and putting all installs
in a DevTools directory for developers to download and install.

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Monica Sanchez
Sent: Tuesday, October 03, 2006 2:49 PM
To: perforce-user at perforce.com
Subject: [p4] encapsulation of third party software

Hi,



This question is not 100% related to perforce but to the OS. Most of my
experience is with UNIX systems, but I'm working with Windows now and
I'll like to know how you manage the third party software. My main goal
is to identify and manage tools that "maybe" affect the OS directories
for DLLs and libraries files.



While I was working on UNIX I had this big application file system,
where most of the applications were installed and all the users run this
application from the same place.



Using Windows, most of the tools affect user account, OS directories and
also the registry.



My goal is to implement a process where I can come back to previous
releases, just sync the source from perforce and then be able to build
them.

Our build process is now defining system and registry variables, so I'll
have not problems with the path or any other variable.



How do you manage these tools for previous releases?

Thanks,

Monica



_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user