coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

It's good to remember that this is an "intermediate format" that is compiler independent. For the most part, it's not even necessary for a developer to ever *have* to work with these files directly.  The primary use of this tool is to assist in the shallow-forking of libraries and apps.

Having built one tool to make project files from arbitrary data, I can guarantee that this works for non-trivial programs (I did the entire PHP stack on Windows-around 4.5 million lines of code, generated 135 project files).

I found with that tool, I really wanted to have an intermediate point that I could generate project files for specific files from.

This isn't reinventing nant or msbuild-those formats don't lend themselves to translation to other formats very easily at all. I'm not building a make tool here, I'm building something to assist in normalizing build scripts.  Msbuild is one of the build script targets that I'm targeting with the tool following mkSpec.

G


From: John McNamee [mailto:jpm@xxxxxxxxxxxx]
Sent: Wednesday, October 20, 2010 5:22 AM
To: Garrett Serack
Subject: Re: [Coapp-developers] The insanity that is mkSpec

<devils-advocate>

I don't see a crisp separation between the "what" and "how".  Is such separation even possible for non-trivial programs?  How much benefit is there to having separate files (with a different syntax) where one is mostly "what" and the other is mostly "how"?

More generally, isn't this just reinventing the nant or msbuild wheel?

</devils-advocate>


-------- Original Message --------
Subject: [Coapp-developers] The insanity that is mkSpec
From: Garrett Serack <garretts@xxxxxxxxxxxxx><mailto:garretts@xxxxxxxxxxxxx>
To: coapp-developers@xxxxxxxxxxxxxxxxxxx<mailto:coapp-developers@xxxxxxxxxxxxxxxxxxx>
Date: 10/19/2010 2:29 PM

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;
}