[patch] imply file by filein in package.xml, usually

smalltalk--backstage--2.2--patch-51
    imply file by filein in package.xml, usually

This only happens during XML parsing, so the Package protocol is
unchanged.  You can short-circuit it with an explicit <file> or
<built-file> or <other future allFiles-integrated tag>.  The idea is to
simplify description and eliminate common errors for the most common
case, in which you want a <file> for each <filein>.

--
;;; Stephen Compall ** http://scompall.nocandysw.com/blog **
;;; acolyte of the indirect effect

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Stephen Compall wrote:
> smalltalk--backstage--2.2--patch-51
>     imply file by filein in package.xml, usually
>
> This only happens during XML parsing, so the Package protocol is
> unchanged.  You can short-circuit it with an explicit <file> or
> <built-file> or <other future allFiles-integrated tag>.  The idea is to
> simplify description and eliminate common errors for the most common
> case, in which you want a <file> for each <filein>.

I'm not sure actually of the patch, though I see what you want to achieve.

The best thing would be to add fileins automatically to either <file> or
<built-file> using something like

    <filein dist="yes|no">

with the default being yes.  Then, you could use <file> for data files
only.  However, this is probably too much for the pseudo-XML parser I'm
using now (unless you want to use some regular expression magic).

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sat, 2007-07-21 at 09:32 +0200, Paolo Bonzini wrote: The extra verbosity would greatly reduce the benefit of implying
anything versus just specifying <built-file> explicitly, e.g.:

  <filein dist="no">something.st</filein>
v
  <filein>something.st</filein>
  <built-file>something.st</built-file>

As built-file is much rarer and is likely to remain so, requiring
explicit specification is not too much of a burden, and is anyway more
self-documenting.

In addition, this flag would close off other types of packaged files.  I
am not sure what those would be, but dare not limit the domain to that
of my imagination at this late hour.  :)

--
;;; Stephen Compall ** http://scompall.nocandysw.com/blog **
;;; acolyte of the indirect effect

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

>> The best thing would be to add fileins automatically to either <file> or
>> <built-file> using something like
>>
>>     <filein dist="yes|no">
>
> The extra verbosity would greatly reduce the benefit of implying
> anything versus just specifying <built-file> explicitly, e.g.:

Sorry.  I was not clear.  In my proposal there would be four possibilities:

     <filein>foo</filein>
     <filein dist="no">foo</filein>
     <file>foo</file>
     <built-file>foo</file>

where the first two imply <file> and <built-file> respectively.
Furthermore, the first one would be equivalent to

     <filein dist="yes">foo</filein>

> In addition, this flag would close off other types of packaged files.  I
> am not sure what those would be, but dare not limit the domain to that
> of my imagination at this late hour.  :)

That is fixed by choosing a different attribute (e.g. type="built" vs.
type="dist").

Note that I'm not against <filein> implying <file> by default, also
because every <filein> must be in practice a <file> or a <built-file>.
I'm against the way you specify that this default should be overridden.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk