Trying to setup a dev definition.

[Robin Lee Powell]

So I understand that mudballs is not so much designed to work with
the dev tree for a system, but I kind of need to make it so we can
use mudballs' documentation generation system.

I can imagine ways around that, but only ugly ones.

Anyways, I'm really not sure where to start. The application is
Weblocks, and looking at the system-definition that comes with
mudballs for weblocks is a bit frightening. It's very long
and complex. Example:

(:components
(:src module
(:components
"weblocks"

(:UTILS MODULE
(:serial t)
(:components "misc" "typespec" #+(or openmcl mcl) "dfun-mcl")
(:needs ("weblocks")))

("application" (:needs "weblocks"))

("page-template" (:needs "weblocks" :utils "application"))
("actions" (:needs "weblocks" :utils))
("debug-mode" (:needs "weblocks" "actions"))

Questions that arise from that:

1. (Most important) Is there code somewhere to generate this
stuff? It sure *looks* autogenerated.

2. (:serial t) ?

3. What does ":needs" mean at the file level like this? I mean,
given that "actions" was already listed as part of the system,
what difference does it make that "debug-mode" needs "actions"?
That is, what does the system do in response to that specification?
The ":needs "weblocks"" all over the place is even wierder, and just
seems totally meaningless.

I want to be able to do something like a nightly grab-the-latest and
make-.mdb-file script, but I'm pretty stumped by this stuff.

Thanks for the help.

-Robin

--
They say: "The first AIs will be built by the military as weapons."
And I'm thinking: "Does it even occur to you to try for something
other than the default outcome?" -- http://shorl.com/tydruhedufogre
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/

[Leslie P. Polzer]

> So I understand that mudballs is not so much designed to work with
> the dev tree for a system, but I kind of need to make it so we can
> use mudballs' documentation generation system.

Where exactly is the problem?

> Questions that arise from that:
>
> 1. (Most important) Is there code somewhere to generate this
> stuff? It sure *looks* autogenerated.

Yes, I think Mudballs comes with a converter for ASDF systems.
Check back with Sean to make sure.

> 2. (:serial t) ?

Serial dependencies: every component depends on those declared
before it.

> 3. What does ":needs" mean at the file level like this?

A :NEEDS B <=> A depends on B, thus B has to be loaded before
A (with A and B being files, components or modules at will).

> I mean, given that "actions" was already listed as part of the system,
> what difference does it make that "debug-mode" needs "actions"?

The correct load order is established.

> That is, what does the system do in response to that specification?

Load the files in correct order. :)

> The ":needs "weblocks"" all over the place is even wierder, and just
> seems totally meaningless.

No. Components with that specifier need weblocks.lisp to be loaded
first. Does it still seem weird?

Leslie

[Sean Ross]

On 24 Mar 2009, at 07:52, Robin Lee Powell wrote:

>
>
> So I understand that mudballs is not so much designed to work with
> the dev tree for a system, but I kind of need to make it so we can
> use mudballs' documentation generation system.
>

This isn't quite true, while Mudballs does focus on delivering
released versions of systems there is nothing stopping you
from running development versions of a system on your own machine, in
fact, this is what I do on a regular basis with
my own systems.

Typically this involves having a <name>.mbd file in the root directory
of your system along with an entry in your ~/.mudballs file
which adds a search path to sysdef:*custom-search-modules*.

You can find some more detail about this at http://mudballs.com/#your-system
(and in the sections above it).

>
> Questions that arise from that:
>
> 1. (Most important) Is there code somewhere to generate this
> stuff? It sure *looks* autogenerated.

It's not autogenerated I'm afraid but isn't really any more complex
than the equivalent ASDF version.
While manually converting the definitions I have tried to keep to as
similar a definition as possible rather
than doing any changes myself.

Also, remember that :weblocks has a rather complex system definition
multiple modules all with very precise
dependency specifications. For a simpler example you should take a
look at Edi's systems (hunchentoot is a good example)
which has serial dependencies.

For the rest, `What Leslie said`.

Cheers,
Sean.