coapp-developers team mailing list archive

[Philip Allison <mangobrain@xxxxxxxxxxxxxx>]

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> 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 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.
>
>
>
>
>
>