coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

Well, ‘events’ is a bit hairy… essentially they are order-sensitive-custom-tool-actions… (which is what they call Build Events  in VC++ ) They aren’t really expressable in property sheets, so they’ve remained in the project layout. It’s not a perfect metaphor, but it’ll have to do.

It’s possible that those should be moved out as well; I’ll have to think about that some more.

I think for CoApp version 1, we’re going to forego ‘optional’ dependencies. I’m not a big fan of optional dependencies, I think that either you use a piece of code or you don’t… Of course, the other way to handle it is to build two ‘flavors’ of the same package, one with and one without the optional dependency (which is probably better anyway).

Ideally, these files aren’t of great interest to the average developer—they are useful to see what the scan/trace/user data has come up with for purposes of making useful project files for a given project. (which is mkProject’s job).

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: Philip Allison [mailto:mangobrain@xxxxxxxxxxxxxx]
Sent: Tuesday, October 19, 2010 3:38 PM
To: Garrett Serack
Cc: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] The insanity that is mkSpec


Hmm.. interesting concept, but it does raise a few questions for me.  I'm no expert, but know enough about supposed compiler-agnostic build systems to know I wouldn't like to design one myself. ;)

Firstly, it strikes me that "what" and "how" are a bit mixed up in the XML with the inclusion of events... which may be an issue simply of terminology, but there are surely problems to be solved regarding portability in the face of reliance on  external tools (shells, interpreters), and questions regarding how/whether variables and other derived information is presented for use in event scripts.  Secondly, is the definition of dependencies and build targets rigid for a given XML & CPS pairing, or is there scope for build options with user-defined values?  If the latter, how do you envisage this looking in the spec files/being presented to the user?  I'm thinking optional dependencies, install prefixes, etc...

If I'm missing the point, or have misinterpreted the scope of this stuff, please enlighten me.  Describing in a nutshell something you've been thinking about for so long isn't easy. :)

Regards,
Phil
On 19 Oct 2010 20:30, "Garrett Serack" <garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx>> wrote:
> 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: garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx><mailto: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.
>
>
>
>
>
>