Profile splitting time!

Neven Has haski at sezampro.yu
Thu Nov 22 08:34:06 PST 2001


On Wed, Nov 21, 2001 at 06:36:55PM +0000, Mark Ellis wrote:
> I was thinking more of <include> having the location directly, but 
> this gives room for expansion.

One thing that I had in mind is:

<include type="package"> <!-- "profile" for the way it works now -->
	<name>gtk</name>
	<version>1.2.10</version>
	<location>large_profile.xml</location>
</include>

which would include a single <package> from the profile stated in <location>.

That would be useful for those wanting to keep instructions for multiple 
packages in a single profile. For example, I remember Paul Campbell had
a profile called mother.xml with tons of <packages>s in it. So with the
above, one could just select and include only some of them.

> One thing I'm curious about, do you know if 
> it's possible to use entities from the master profile in an included one ? 
> I know it won't as you've written it, or at least i dont thnk it will, i'm 
> just wondering if we can do it ? This would then allow you to change 
> globals in the master, such as "LFS", without worrying about the 
> sub-profiles. My thinking is if you could create a parser for the sub 
> profile, copy the entity list into it from the master, then parse the sub. 
> I have no idea if this is possible, any idea ?

It's possible, but not in some clean way (at least I don't see it yet).

I don't think that there is a way to copy the entity list from parser to
parser (since resolving entities is probably the first thing parser does),
but we could trick him. :) We could feed the sub-parser with our own created
entity declarations, using the entities from the main parser. Right after
the sub-parser's start handler for Doctype is called is a good time to do
that. All this belongs to "I think" category. :)

Anyway, if we try something like that, should we do it by default, or only
when requested?

I don't think it should be default, since the profiles included would be
again dependent of their master profile, which is not always suitable.
And it wouldn't be "pure XML" any more.


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