Howdy! I'm glad you like it... I've been mulling this over for a long time, but I didn't get the inspiration for the cascading sheets until last week... and then I started playing through scenarios in my mind and this is where it took me.
It'll be covered under the Apache license, like everything else for CoApp. I only came up with the name this morning :D I'm going to write a proof-of-concept (aka version 1) over the next few days and I'll see how it turns out. Once I have it running, I'll start a wiki page for it. G 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: Roberto Carlos González Flores [mailto:iscrobertogonza...@gmail.com] Sent: Tuesday, October 19, 2010 1:28 PM To: Garrett Serack Cc: coapp-developers@lists.launchpad.net Subject: Re: [Coapp-developers] The insanity that is mkSpec Hi, Garret, IMHO this is awesome, I never heard about CPS before. It's a great idea, I wonder If I can use it with another Open Source projects, inHouse Projects, etc... or if it's going to be licensed?, it's your idea?, :D. Maybe a Wiki page will be great for this. Cheers! 2010/10/19 Garrett Serack <garre...@microsoft.com<mailto:garre...@microsoft.com>> Rafael and I have spent a bunch of time over the last several days hashing out an idea for the 'spec' file format for the mkSpec tool. The idea with these files, is that they are a coapp-specific, compiler independent way of looking at project files that can be used by another tool to generate project files (or makefiles, or cmake files, or whatever) for compiling with an individual compiler. I knew from past experience, that I wanted to separate out the "What" from the "How" a project gets built. The "What" is basically the project structure without any real assertions as to how the files get assembled into a final project. This should be something that a developer can read that gives them the understanding of what goes into a particular target. The "How" gives the project file context as to how each individual file is used in the final build file. This affects where it picks up include files, what #defines are declared at the command line, etc (basically everything you see in the project settings window). I spent a lot of time trying to understand how to properly represent this data, and then it hits me: split the two types of information into two different files, one XML that represents the structure (the "What") and one that represents the properties applied to that (the "How"). XML was not appropriate for the second one, but CSS was... so I've come up with "Cascading Property Sheets" (.cps) which are the essentially the 'style' applied to the project structure. So, mkProject-vc10 takes these two files, it generates a .VCXPROJ project file that builds the way that is expected. The following is an example of what I'm thinking. I'm on #coapp on irc at freenode if ya want to talk about it... ( irc://irc.freenode.net/coapp<http://irc.freenode.net/coapp> or http://webchat.freenode.net/ ) =====[ foo.spec ]======== <?xml ?> <target propertysheet="build.cps" > <dependency name="zlib" version="*" /> <dependency name="somelib" version="1.2.3.4" /> <group name="source files" id="sourcefiles" > <file id="./path/to/foo.c" /> </group> <group name="header files" id="headerfiles" path="./path/to/"> <file id="./path/to/foo.h" /> </group> <group name="resources" id="resources"> <file id="./path/to/somefile.rc" /> <file id="./path/to/resources.h" /> <file id="./path/to/bitmap.bmp" /> </group> <group name="manifest files" id="manifest"> <file id="./path/to/foo.exe.xml" /> </group> <event condition="prebuild" priority="1"> <script language="cmd"> @echo off echo this script does something odd. </script> </event> <link output="foo.exe" /> </target> ====================== =====[ foo.cps]======== /* Cascading Property Sheet */ /* Selectors can apply to any node, and appropriate property styles cascade down to child nodes */ group { /*by default, files are not compiled with any tool*/ compile-as:none; } group[sourcefiles] { compile-as:c; /* overiding compile-as makes it compile */ read-only-string-pooling:on; define:X86=1; define:HAS_ZLIB; include-directory:"c:\\apps\\directory\\include"; include-directory:"c:\\apps\\zlib\\include"; } group[resources/id$=".rc"] { compile-as:resource; /* only compile the .rc files */ } file[./path/to/file.c] { define:HAS_OTHERLIB; } ====================== [Description: fearthecowboy]<http://fearthecowboy.com/> Garrett Serack | Microsoft's Open Source Software Developer | Microsoft Corporation Office:(425)706-7939 email/messenger: garre...@microsoft.com<mailto:garre...@microsoft.com> blog: http://fearthecowboy.com<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 Post to : coapp-developers@lists.launchpad.net<mailto:coapp-developers@lists.launchpad.net> Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp -- Carlos
<<inline: image001.gif>>
_______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
