Syntax, shall we?

Neven Has haski at sezampro.yu
Thu Jan 24 10:15:24 PST 2002


On Thu, Jan 24, 2002 at 03:59:54AM -0800, Jesse Tie-Ten-Quee wrote:
> Allright, let's get this big ball of wax started.
> 
> First, I want to express that all suggestions are welcome and will be
> considered and discussed, at least as much as we can.
> 
> I was going to start off by posting a few new ideas i had with the
> syntax, but i want to hear from a few people first that have mentioned
> they have a few ace's up there sleeves. (*waves at Neven*)

*waves back* :)

I was waiting for your ideas, since these below are more or less old
and already discussed. But still, a new point of view is also desperately
needed for these - there might be a lot of flows in there.

First, these are all "relative" to the syntax used by both Perl ALFS
and nALFS, which is a small (at least it was at the beginning) modification
of the one from ADG.

Unfortunately there isn't a document describing this current syntax, so
the best thing one can do is check out the profiles written using it.

Which raises the question - what should we use to refer to current syntax
we are now working on?

ADG-like document is great when syntax is complete, for the profile
writer (or developer) to start writing profiles (or implementations) but,
IMHO, it's not that practical for discussing and improving the syntax
at this stage.

I think DTD could serve us well for this, it's not that hard to understand,
even for someone who doesn't know it that well (like me for example :).

Mark has one at:
http://freespace.virgin.net/mark.uzumati/profiles/alfs-dtd-2.0.2.xml.

Not everything is represented with it (for example the values of <options>
for different elements), but we could add some comments to it and make
it really useful for this.

I could send it here (or better first to Mark, to correct my mistakes :),
modified like that, to show what I mean.

Second, not all of the below are mine ideas. Some are from my various
TODO and TODISCUSS :) lists, and with some of them I might not even agree
that much.

They are just thrown here, in no particular order:

o   The question Mark raised is whether we should force the order for
    certain elements or not. For example, in:

        <configure>
            <base>&build_dir;/&automake-directory;</base>
            <param>--prefix=/usr</param>
        </configure>

    does <base> _have_ to go first, before <param> or not.

    If we start using DTD for validating profiles, it seems (I'm not
    the expert) that some ordering will have to be forced?

    Personally I'm not for that kind of forcing. We could just add a note
    (to the official syntax document in the future) that if you want to
    validate your profiles with DTD you'll have to be careful with the
    order of elements. Or something like that.

o   Should we have that <include> in the syntax? This element seemed like
    a great thing at first, but now I'm not that sure.

    As someone already mentioned, it could cause some problems in the
    future, if we start using some third party XML software. For example,
    XML editor won't include another profile when it encounters <include>,
    it will just leave it be. It could be said that this element "breaks
    the XML" in a way. (Don't take this literally. :)

    For what it's used now, something like XInclude can easily replace it.

    But, on the other hand, we won't be able to expend it to suit our
    needs if we start using XInclude instead. There is so much stuff that
    could be added to our own <include> that would allow implementations to
    do a lot of nice things. For example, by specifying remote url like:

        <location type="remote">
            http://automated.linuxfromscratch.org/LFS-3.1/bash.xml
        </location>

    implementation could either launch some program to grab that profile,
    checking if it's successfully transferred, and acting accordingly. Or,
    have it's own code for grabbing the profile with some nice status
    reporting or other similar perversions.

o   What I think is a very good idea is something like:

        <package>
            <package_info> <!-- name is just an example -->
                <name></name>
                <version></version>
            </package_info>

            <package_building_instructions> <!-- name is just an example -->
                <prebuild></prebuild>
                <build></build>
                <postbuild></postbuild>
            </package_building_instructions>
        </package>

    As I said on this list, it always bothered me a bit that info like name
    and version of the package are on the same level as prebuild, build
    and postbuild information. All together inside <package>.

    I think profile would be much more readable if we split that
    information.

    Then, latter, we could also add things like <location>, <homepage>,
    <description>, <author> - all in <package_info> - without "polluting"
    the <package> itself.

    Note that this change would break the profiles (at least with current
    implementations), but I think it's worth it.

o   New element - <group>, or similar - was suggested here. Inside it, all
    the regular elements are to be found. For example it could look like:

        <group>
            <name>dirs_in_usr</name>
            <description>Creating directories in /usr</description>

            <instructions>
                <mkdir></mkdir>
                ...
            </instructions>
        </group>

    Personally, I don't thing this is necessary. I do agree that it might
    improve the look of the profiles and make them more readable perhaps,
    but if people decide that something like this should be included in
    the syntax, I don't thing it should become mandatory (all elements in
    some <group> or <package>).

o   Thanks to Fabien Steinmetz, there is:

        <setenv mode="append">
            <variable>PATH</variable>
            <value>:/static/bin</value> <!-- Sounds familiar? ;) -->
        </setenv>

    now, implemented in nALFS.

    I think this can be very useful (think about PATH above) and perhaps
    added to the syntax?

o   One general thing - where ever possible, I think we should allow
    multiple content in elements, separated with whitespace. For example:

        <unpack>
            <archive>
                &LFS;&packages_dir;/&binutils-package;
                /alternative/location/if/first/one/fails/&binutils-package;
            </archive>

            <destination>&LFS;&build_dir;</destination>
        </unpack>

o   Should we rename <base>? I never liked that name much, but I still
    didn't want to use <dir> - this is the working directory for the most
    elements and I think it should be as descriptive name as possible.

    But as someone said, we kind of got used to it. :)

I might add a few more ideas latter, when I remember them. :)

All in all, I think that the current syntax is pretty close to something
we could all agree to use.


Neven

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message



More information about the alfs-discuss mailing list