coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

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  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: garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx>
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.