Re: [Vala] Introducing Realise (prototype 1)

[Phil Housley <undeconstructed gmail com>]

2009/10/29 Abderrahim Kitouni <a kitouni gmail com>:
> Hi,
>
> 2009/10/15, Phil Housley <undeconstructed gmail com>:
> > If anyone has any interest in trying out my code, please realise that
> > it is very early stage, and makes a lot of assumptions - for example,
> > when compiling it will always invoke the first "valac" and "gcc"
> > binaries in the path.  Also, it currently needs an outdated version of
> > libcore[1], patched to support a tiny bit of extra xml.  If anyone has
> > the patience to try it, I would be very grateful, any changes needed
> > to get it to run will be accepted.
>
> I've just had the patience to try it (libcore relies on the
> vala-support script which is incompatible with my version of
> automake), attached are the patches I made (the one for libcore is
> somewhat a hack, you need to install the vapi and header manually).

Thankyou for having the patience!  I'd rather got the idea that I
really should make it a bit more accessible before trying to get
anyone else involved, but I hadn't yet decided exactly how to do that.
 Moving away from Core would certainly help, but I do like its wider
reach beyond just the containers of libgee.

> I got it to run and to build itself. I'm a bit annoyed that it is too
> verbose (although I like a program to print what it's doing, this is
> too much).

Yes, it is over the top, but then it is still very early on.  All it
does is GLib.message all over the place, so really it's all just
trace.

> the project.xml mentions the path to vpl as main, while it is
> src/main/vala (I find this inconsistent, and I don't like deep
> nesting).

I lifted that straight from Maven, without even really thinking about
it.  The idea is that:
src/ is all source code for the project, as opposed to docs, config, whatever
main/ is the primary module of the project.  This is diverging a bit
from Maven, but with the same name.
vala/ is all vala source, which could be alongside bits in any other languages.

More sensible would probably be to lift a standard autotoolsy layout,
of /main, or /appname, but it's not an architectural change, just a
policy thing.

> I think that we should focus more on what it should do rather than
> how. We could for example write a build file for Vala (the compiler),
> and start implementing what's needed for it.

That is entirely true.  You probably were able to guess how I began
this project - the multithreaded engine is far more than is needed for
building the 5 or 6 source files, because I started off with the idea
of trying to do parallel builds and then built on top of that.

What I've been doing recently is trying to actually work out the
things I should have started with, like a general build plan to use to
direct the processing.  The next thing I code will hopefully be an
implementation of that plan, and to use it to kick off the build,
instead of the hard coded thing there now, which just assumes you have
some vala source and want a binary made out of it.  I have some ideas
sketched out for the general workflow, but I think coding it would be
the best way to find out if they are reasonable, so I'll leave out the
details for now.

> Does this make any sense to you?

Lots.  Thanks for your thoughts.

> Regards,
> Abderrahim

-- 
Phil Housley