Very True. As a matter of fact, I'm really big fan of multiple ways to do the exact same job. In the digital identity world, we called that a "Pluralism of Operators and Technologies". If there is only one way, it's not a very smart thing.
Want more proof? Since we clearly don't need more than one text editor, let's get rid of them all, and go with the one true way. Of course, I'm talking about WordStar. You didn't really think I meant VI or Emacs, right? LOL Garrett Serack | Open Source Software Developer | Microsoft Corporation I don't make the software you use; I make the software you use better on Windows. From: coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net [mailto:coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net] On Behalf Of Adam Baxter Sent: Tuesday, April 13, 2010 1:11 AM To: Andrew Fenn Cc: coapp-devel Subject: Re: [Coapp-developers] How exactly will CoApp come together? As the package spec will be available to all, there's no reason there couldn't be multiple tools to do the same job. I'm already thinking about a tool to package Python programs for MSI/CoApp. On Tue, Apr 13, 2010 at 2:48 PM, Andrew Fenn <[email protected]<mailto:[email protected]>> wrote: Is there a reason to collect all the data using this scantool other then to make a build file? Surely it would be less work to just manually setup VS project files, cmake, etc then it would be to build a tool that auto generates them? I admit I'm a big fan of CMake and I know CPack exists that makes packages out of your programs. What I am wondering is if you could save a lot of development time by using cmake? You would not need to make the ScanTool and mkSpec programs. If you contributed to CPack then you could make it generate an MSI installers and that would mean you wouldn't need to make a mkPackage program either. I'd hate to see you put in a lot of development time when the tools you need already exist, or perhaps I'm not understanding the whole picture of package building correctly? On Tue, Apr 13, 2010 at 1:23 AM, Garrett Serack <[email protected]<mailto:[email protected]>> wrote: So, I've been taking questions as to how CoApp packages get built. Lemme see if I can sketch out the vision for you, so that you get an idea of where it's going. This isn't set in stone, but I've actually validated this is a workable solution. Let's say I want to create a library package for zlib. First, I'm going to import the zlib source code into a Bazaar in a new CoApp sub-project on Launchpad. Checking out from there, I'll first see if the project can be compiled at all using MSVC (any version). If it has an older project file, I'll load it up in Visual Studio 10, and let it upgrade the project, and I'll save it. Drop back to the command line. The SCANTOOL file can be pointed to the source directory to scan thru all the source files and build files to generate some intelligence about the project as a whole. It gets a list of all source files (C,C++,.H, etc), potential conditional defines present in the source (#define FOO ...) and identifies what additional files are present in the project (for which we'll have to determine what to do with them (delete, include in final as resources, ???). SCANTOOL dumps all of this data into an XML intelligence file for the project. Build the project (either by the makefile, the vcprojx file, or whatever means necessary). When doing so however, use the TRACE tool to watch the library get built. TRACE creates an XML file with every file access, write, read, delete and every command line for the build process and all its child processes. At this point the developer can create a hand-made intelligence file as well for things that are known about the project (what targets are desired, etc). The intelligence files and the trace data are fed into another tool MKSPEC, which creates a set of .spec files, each of which describes a binary output desired from the project (a .LIB , .DLL, .EXE, etc) and lists the files needed, conditional #defines, and other options. (this is essentially a compiler-neutral way of representing what is needed to build a particular output) Each .spec file is then fed into MKPROJECT which will generate a VC10 project file. Plugins for MKPROJECT can trivially build other types of project files for things like VC9, make files for MinGW or CMake files for the CMake faithful. MKProject also ties together a collection of project files into a .SLN file for Visual Studio. Outputs are normalized for naming conventions. The .SLN file is fed into Visual Studio (or MSBuild, the command line tool) and it compiles up the binaries. (I've got a plan for PGO as well, [profile guided optimization], but I'm going to ignore that right now) The binaries are fed into a tool called SMARTMANIFEST which creates .manifest and policy files for the library and binds them to any .DLLs and .EXEs created. The binaries (and manifest data) along with the project source code and build files are fed into MKPACKAGE which uses WiX to build MSI files for each binary, along with a source MSI with just the necessary files to rebuild the binaries (source, vcxproj, sln). At that point the developer can identify what files can be trimmed from the source tree, and the whole thing can be updated in Bazaar. http://twitpic.com/rqmo5 -- a flowchart of what I just described. Well, without TRACE. (there's a lot more detail to be found, but that's the gist of it) <http://fearthecowboy.com/> Garrett Serack | Microsoft's Open Source Software Developer | Microsoft Corporation Office:(425)706-7939 email/messenger: [email protected] blog: http://fearthecowboy.com twitter: @fearthecowboy<http://fearthecowboy.com/> I don't make the software you use; I make the software you use better on Windows.<http://fearthecowboy.com/> <http://fearthecowboy.com/> <http://fearthecowboy.com/> <http://fearthecowboy.com/> _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp<http://fearthecowboy.com/> <http://fearthecowboy.com/> _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp<http://fearthecowboy.com/> <http://fearthecowboy.com/>
_______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
