coapp-developers team mailing list archive

[Nasser Dassi <nasserd@xxxxxxxxx>]

I don't know what's worse... *Word Star* or the 16-bit icons released with
Windows 3.1?

- nasser

On Tue, Apr 13, 2010 at 10:42 AM, Garrett Serack <garretts@xxxxxxxxxxxxx>wrote:

> *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.com@
> lists.launchpad.net [mailto:coapp-developers-bounces+garretts<coapp-developers-bounces%2Bgarretts>
> =microsoft.com@xxxxxxxxxxxxxxxxxxx] *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 <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)
>
>
>
>
>
> <http://fearthecowboy.com/>
>
> *Garrett Serack | Microsoft's Open Source Software Developer | Microsoft
> Corporation
> Office:(425)706-7939                                       email/messenger:
> garretts@xxxxxxxxxxxxx <http://fearthecowboy.com/>*
> *
>
> 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     : *coapp-developers@xxxxxxxxxxxxxxxxxxx*
> 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     : *coapp-developers@xxxxxxxxxxxxxxxxxxx*
> 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     : coapp-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~coapp-developers
> More help   : https://help.launchpad.net/ListHelp
>
>