coapp-developers team mailing list archive

[Adam Baxter <voltagex@xxxxxxxxxxxx>]

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 <andrewfenn@xxxxxxxxx> 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 <garretts@xxxxxxxxxxxxx>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)
>>
>>
>>
>>
>>
>> [image: Description: fearthecowboy] <http://fearthecowboy.com/>
>>
>> *Garrett* *Serack* | Microsoft's Open Source Software Developer | *Microsoft
>> Corporation
>> Office*:(425)706-7939                                       *email*/*
>> messenger*: garretts@xxxxxxxxxxxxx
>> *blog*: http://fearthecowboy.com                                      *
>> twitter*: @fearthecowboy <http://twitter.com/fearthecowboy>
>>
>> *I don't make the software you use; I make the software you use better on
>> Windows.***
>>
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~coapp-developers<https://launchpad.net/%7Ecoapp-developers>
>> Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~coapp-developers<https://launchpad.net/%7Ecoapp-developers>
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~coapp-developers<https://launchpad.net/%7Ecoapp-developers>
> Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~coapp-developers<https://launchpad.net/%7Ecoapp-developers>
> More help   : https://help.launchpad.net/ListHelp
>
>