What is task-base?

What is task-base?

[Richard Purdie]

I've been asked to explain exactly what my last commits did. Basically,
I broke us free from being tied to task-bootstrap by creating
MACHINE_TASK_PROVIDER which you can set to the task-bootstrap like
provider of your choice. It defaults to task-bootstrap so nothing
changes in that respect.

I then changed the zaurus machines to use a new alternative called
task-base. Instead of having each machine setting a ton of duplicate
variables, this aims to allow a machine to specify its features and
task-base builds it a customised task-bootstrap like package based on
what the machine needs along with what the distro supports. At present,
task-base supports the Zaurus 2.6 models but adding support for other
machines should be straightforward.

To illustrate, the distro.conf file can say:

DISTO_FEATURES = "nfs smbfs ipsec wifi ppp alsa bluetooth ext2 irda
pcmcia usbgadget usbhost"

and the machine.conf:

MACHINE_FEATURES = "kernel26 apm alsa pcmcia bluetooth irda usbgadget"

and the resulting task-base would support say pcmcia but not usbhost.
task-base details exactly which options are either machine or distro
settings (or need to be in both). Machine options are meant to reflect
capabilities of the machine, distro options, things distribution
maintainers might want to add or remove from their distros images.
Hopefully this will let people create customised versions of
"task-bootstrap" without impacting other OE users/distros.

As one extreme, if you want to create an extremely minimal image, you
could set DISTRO_FEATURES = "" and you'd stop a lot of packages making
it into the image.

Its not perfect yet but we needed to set the ball rolling somehow :)

Cheers,

Richard

Re: What is task-base?

[Marcin Juszkiewicz]

Dnia niedziela, 27 sierpnia 2006 23:46, Richard Purdie napisał:

> I've been asked to explain exactly what my last commits did. Basically,
> I broke us free from being tied to task-bootstrap by creating
> MACHINE_TASK_PROVIDER which you can set to the task-bootstrap like
> provider of your choice. It defaults to task-bootstrap so nothing
> changes in that respect.

I like that idea :) Will have to look at it and add to .oz354x branch so 
it will be much easier to create working images for collie.

> Its not perfect yet but we needed to set the ball rolling somehow :)

I think that we lack "serial" in MACHINE_FEATURES - this would be needed 
by "irda" feature but will be also useful for machines which have normal  
serial (RS232/RS485) here we can put lrzsz.

"pcmcia" feature should recommend "serial", "bluetooth", "wifi" features 
atleast. It also contain now hostap-cs without checking for "wifi".

"ext2" feature could be renamed to kind of "internal-storage" - most of 
our supported devices use ext2 but not every of them has internal storage 
with ext2.

"wifi" feature need some work too. There are machines which does not have 
Prism based wifi cards (so no need for hostap-utils) or do not support 
WPA (wpa-supplicant is not needed then). h4000 has internal wifi on 
ACX100 chipset (iirc) so it need only wireless-tools to have it working 
(chipset related packages should be listed in machine config).

-- 
JID: hrw-jabber.org
Palmtop: Sharp Zaurus C760
OpenEmbedded/OpenZaurus developer

          Warning: Dates in calendar are closer than they appear.

Re: What is task-base?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcin Juszkiewicz schreef:
<snip>


> "wifi" feature need some work too. There are machines which does not have 
> Prism based wifi cards (so no need for hostap-utils) or do not support 
> WPA (wpa-supplicant is not needed then). h4000 has internal wifi on 
> ACX100 chipset (iirc) so it need only wireless-tools to have it working 
> (chipset related packages should be listed in machine config).

Which leads to the question: "how should they be listed?". At the moment a lot of machines
just put those modules in BOOTSTRAP_*, which isn't going to work for things that don't use
task-bootstrap (the Ångström distribution for example). A few weeks ago I introduced the
'BOOT_MODULES' variable for that, should we add that to all machines, or is there a nicer
way to do that?

regards,

Koen


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFE8rn8MkyGM64RGpERAiGoAJ4iZXPJAznbdhOWyvfHrh2vIr01qACfdoWq
E8t878wEV+zh65WYkdNP7X0=
=YVbQ
-----END PGP SIGNATURE-----

Re: What is task-base?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
> Marcin Juszkiewicz schreef:
> <snip>
> 
> 
>>> "wifi" feature need some work too. There are machines which does not have 
>>> Prism based wifi cards (so no need for hostap-utils) or do not support 
>>> WPA (wpa-supplicant is not needed then). h4000 has internal wifi on 
>>> ACX100 chipset (iirc) so it need only wireless-tools to have it working 
>>> (chipset related packages should be listed in machine config).
> 
> Which leads to the question: "how should they be listed?". At the moment a lot of machines
> just put those modules in BOOTSTRAP_*, which isn't going to work for things that don't use
> task-bootstrap (the Ångström distribution for example). A few weeks ago I introduced the
> 'BOOT_MODULES' variable for that, should we add that to all machines, or is there a nicer
> way to do that?

And I ask again, before wasting my time implementing it: "should we add that to all
machines, or is there a nicer way to do that?"

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFE+EEbMkyGM64RGpERAkUYAJ40C4JP8W9RyigFOmzt0mnhPkC+SQCZATJH
9UAl50U0N9f3LFdrd9QwwiA=
=ja7C
-----END PGP SIGNATURE-----

Re: What is task-base?

[pHilipp Zabel]

On 9/1/06, Koen Kooi <koen@dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Koen Kooi schreef:
> > Marcin Juszkiewicz schreef:
> > <snip>
> >
> >
> >>> "wifi" feature need some work too. There are machines which does not have
> >>> Prism based wifi cards (so no need for hostap-utils) or do not support
> >>> WPA (wpa-supplicant is not needed then). h4000 has internal wifi on
> >>> ACX100 chipset (iirc) so it need only wireless-tools to have it working
> >>> (chipset related packages should be listed in machine config).
> >
> > Which leads to the question: "how should they be listed?". At the moment a lot of machines
> > just put those modules in BOOTSTRAP_*, which isn't going to work for things that don't use
> > task-bootstrap (the Ångström distribution for example). A few weeks ago I introduced the
> > 'BOOT_MODULES' variable for that, should we add that to all machines, or is there a nicer
> > way to do that?
>
> And I ask again, before wasting my time implementing it: "should we add that to all
> machines, or is there a nicer way to do that?"

I wonder if this shouldn't be modularized a bit, the modules could be
assigned to different base tasks. The ipaq-pxa270.conf puts the
following modules into BOOTMODULES_RRECOMMENDS currently:

PXA270_MODULES = "g_ether g_file_storage g_serial gadgetfs pxa27x_udc \
                  snd_pcm_oss snd_mixer_oss evdev mmc_block pcmcia hidp \
                  nls_cp437 nls_iso8859-1 nls_utf8 af_key"
HX4700_MODULES = "i2c-pxa hx4700_voltage acx hx4700_acx snd_hx4700_audio"

g_ether, g_file_storage, g_serial and gadgetfs are already in
task-base-usbgadget-rrecommends.
snd_pcm_oss and snd_mixer_oss are in task-base-alsa-rrecommends.
hidp is in task-base-bluetooth-rrecommends

This leaves us with

pxa27x_udc evdev mmc_block pcmcia nls_cp437 nls_iso8859-1 nls_utf8 af_key
i2c-pxa hx4700_voltage acx hx4700_acx snd_hx4700_audio

I propose to put pxa27x_udc in task-base-usbgadget-rrecommends (similar to
task-base-irda-rrecommends containing kernel-module-pxaficp-ir).
But what about the rest?

cheers
Philipp

Re: What is task-base?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pHilipp Zabel schreef:
> On 9/1/06, Koen Kooi <koen@dominion.kabel.utwente.nl> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Koen Kooi schreef:
>>> Marcin Juszkiewicz schreef:
>>> <snip>
>>>
>>>
>>>>> "wifi" feature need some work too. There are machines which does not have
>>>>> Prism based wifi cards (so no need for hostap-utils) or do not support
>>>>> WPA (wpa-supplicant is not needed then). h4000 has internal wifi on
>>>>> ACX100 chipset (iirc) so it need only wireless-tools to have it working
>>>>> (chipset related packages should be listed in machine config).
>>> Which leads to the question: "how should they be listed?". At the moment a lot of machines
>>> just put those modules in BOOTSTRAP_*, which isn't going to work for things that don't use
>>> task-bootstrap (the Ångström distribution for example). A few weeks ago I introduced the
>>> 'BOOT_MODULES' variable for that, should we add that to all machines, or is there a nicer
>>> way to do that?
>> And I ask again, before wasting my time implementing it: "should we add that to all
>> machines, or is there a nicer way to do that?"
> 
> I wonder if this shouldn't be modularized a bit, the modules could be
> assigned to different base tasks. The ipaq-pxa270.conf puts the
> following modules into BOOTMODULES_RRECOMMENDS currently:
> 
> PXA270_MODULES = "g_ether g_file_storage g_serial gadgetfs pxa27x_udc \
>                   snd_pcm_oss snd_mixer_oss evdev mmc_block pcmcia hidp \
>                   nls_cp437 nls_iso8859-1 nls_utf8 af_key"
> HX4700_MODULES = "i2c-pxa hx4700_voltage acx hx4700_acx snd_hx4700_audio"
> 
> g_ether, g_file_storage, g_serial and gadgetfs are already in
> task-base-usbgadget-rrecommends.
> snd_pcm_oss and snd_mixer_oss are in task-base-alsa-rrecommends.
> hidp is in task-base-bluetooth-rrecommends
> 
> This leaves us with
> 
> pxa27x_udc evdev mmc_block pcmcia nls_cp437 nls_iso8859-1 nls_utf8 af_key
> i2c-pxa hx4700_voltage acx hx4700_acx snd_hx4700_audio
> 
> I propose to put pxa27x_udc in task-base-usbgadget-rrecommends (similar to
> task-base-irda-rrecommends containing kernel-module-pxaficp-ir).
> But what about the rest?

Yes, what about the rest?

regards,

KOen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFFGm45MkyGM64RGpERAtR6AJ91iCpv7bz9KB+B6nzcesMnVDEl0gCdECqW
Zb1G9WxYfgD47NQHLAMRJbU=
=PjhG
-----END PGP SIGNATURE-----

Re: What is task-base?

[pHilipp Zabel]

On 9/27/06, Koen Kooi <koen@dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> pHilipp Zabel schreef:
> > On 9/1/06, Koen Kooi <koen@dominion.kabel.utwente.nl> wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Koen Kooi schreef:
> >>> Marcin Juszkiewicz schreef:
> >>> <snip>
> >>>
> >>>
> >>>>> "wifi" feature need some work too. There are machines which does not have
> >>>>> Prism based wifi cards (so no need for hostap-utils) or do not support
> >>>>> WPA (wpa-supplicant is not needed then). h4000 has internal wifi on
> >>>>> ACX100 chipset (iirc) so it need only wireless-tools to have it working
> >>>>> (chipset related packages should be listed in machine config).
> >>> Which leads to the question: "how should they be listed?". At the moment a lot of machines
> >>> just put those modules in BOOTSTRAP_*, which isn't going to work for things that don't use
> >>> task-bootstrap (the Ångström distribution for example). A few weeks ago I introduced the
> >>> 'BOOT_MODULES' variable for that, should we add that to all machines, or is there a nicer
> >>> way to do that?
> >> And I ask again, before wasting my time implementing it: "should we add that to all
> >> machines, or is there a nicer way to do that?"
> >
> > I wonder if this shouldn't be modularized a bit, the modules could be
> > assigned to different base tasks. The ipaq-pxa270.conf puts the
> > following modules into BOOTMODULES_RRECOMMENDS currently:
> >
> > PXA270_MODULES = "g_ether g_file_storage g_serial gadgetfs pxa27x_udc \
> >                   snd_pcm_oss snd_mixer_oss evdev mmc_block pcmcia hidp \
> >                   nls_cp437 nls_iso8859-1 nls_utf8 af_key"
> > HX4700_MODULES = "i2c-pxa hx4700_voltage acx hx4700_acx snd_hx4700_audio"
> >
> > g_ether, g_file_storage, g_serial and gadgetfs are already in
> > task-base-usbgadget-rrecommends.
> > snd_pcm_oss and snd_mixer_oss are in task-base-alsa-rrecommends.
> > hidp is in task-base-bluetooth-rrecommends
> >
> > This leaves us with
> >
> > pxa27x_udc evdev mmc_block pcmcia nls_cp437 nls_iso8859-1 nls_utf8 af_key
> > i2c-pxa hx4700_voltage acx hx4700_acx snd_hx4700_audio
> >
> > I propose to put pxa27x_udc in task-base-usbgadget-rrecommends (similar to
> > task-base-irda-rrecommends containing kernel-module-pxaficp-ir).
> > But what about the rest?
>
> Yes, what about the rest?

kernel-module-pxa27x_udc: task-base-usbgadget-rrecommends
kernel-module-pcmcia: task-base-pcmcia-rrecommends

Compile in evdev, mmc_block, i2c-pxa and af_key and be done with it?

kernel modules could rrecommend evdev if it was
compiled as a module, same goes for mmc_block
(let pxamci and asic3_mmc rrecommend it) and i2c-pxa.

kernel-module-pcmcia: task-base-pcmcia-rrecommends

regards
Philipp

Re: What is task-base?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pHilipp Zabel schreef:

>>> I wonder if this shouldn't be modularized a bit, the modules could be
>>> assigned to different base tasks. The ipaq-pxa270.conf puts the
>>> following modules into BOOTMODULES_RRECOMMENDS currently:
>>>
>>> PXA270_MODULES = "g_ether g_file_storage g_serial gadgetfs pxa27x_udc \
>>>                   snd_pcm_oss snd_mixer_oss evdev mmc_block pcmcia hidp \
>>>                   nls_cp437 nls_iso8859-1 nls_utf8 af_key"
>>> HX4700_MODULES = "i2c-pxa hx4700_voltage acx hx4700_acx snd_hx4700_audio"
>>>
>>> g_ether, g_file_storage, g_serial and gadgetfs are already in
>>> task-base-usbgadget-rrecommends.
>>> snd_pcm_oss and snd_mixer_oss are in task-base-alsa-rrecommends.
>>> hidp is in task-base-bluetooth-rrecommends
>>>
>>> This leaves us with
>>>
>>> pxa27x_udc evdev mmc_block pcmcia nls_cp437 nls_iso8859-1 nls_utf8 af_key
>>> i2c-pxa hx4700_voltage acx hx4700_acx snd_hx4700_audio
>>>
>>> I propose to put pxa27x_udc in task-base-usbgadget-rrecommends (similar to
>>> task-base-irda-rrecommends containing kernel-module-pxaficp-ir).
>>> But what about the rest?
>> Yes, what about the rest?
> 
> kernel-module-pxa27x_udc: task-base-usbgadget-rrecommends
> kernel-module-pcmcia: task-base-pcmcia-rrecommends
> 
> Compile in evdev, mmc_block, i2c-pxa and af_key and be done with it?
> 
> kernel modules could rrecommend evdev if it was
> compiled as a module, same goes for mmc_block
> (let pxamci and asic3_mmc rrecommend it) and i2c-pxa.
> 
> kernel-module-pcmcia: task-base-pcmcia-rrecommends

Looks good, please commit it :)

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFFGq5+MkyGM64RGpERAqccAJoDj04Bkh7mkuMj2ybipNhvvjgTFACaAmrz
BHDx3B11/kSyd4QHdfB2bYw=
=NhGN
-----END PGP SIGNATURE-----

Re: What is task-base?

[pHilipp Zabel]

On 8/28/06, Marcin Juszkiewicz <openembedded@hrw.one.pl> wrote:
> I think that we lack "serial" in MACHINE_FEATURES - this would be needed
> by "irda" feature but will be also useful for machines which have normal
> serial (RS232/RS485) here we can put lrzsz.

Are there machines that have neither serial nor irda?

> "pcmcia" feature should recommend "serial", "bluetooth", "wifi" features
> atleast. It also contain now hostap-cs without checking for "wifi".
>
> "ext2" feature could be renamed to kind of "internal-storage" - most of
> our supported devices use ext2 but not every of them has internal storage
> with ext2.

I don't think ext2 shouldn't be a machine feature, but only one of the distro.
Possible uses for ext2 are SD cards, CF cards / microdrives in the CF slot
(pcmcia) or internal storage. I'd say ext2 packages should be pulled if the
machine has any of (sd, pcmcia, internal-hdd) and the distro supports ext2.
(hdparm is not ext2 specific, but ide specific...)

> "wifi" feature need some work too. There are machines which does not have
> Prism based wifi cards (so no need for hostap-utils) or do not support
> WPA (wpa-supplicant is not needed then). h4000 has internal wifi on
> ACX100 chipset (iirc) so it need only wireless-tools to have it working
> (chipset related packages should be listed in machine config).

There should be a task-pcmcia-wifi-rdepends/rrecommends for pcmcia wifi
cards that would only be used if the machine doesn't have internal wifi.
If somebody really needs a second wifi interface, he can be bothered
to install some packages.
If the machine has internal wifi, the needed packages are machine specific -
there could be a variable task-machine-wifi-rdepends (similar to
task-distro-wifi-rdepends)
I'd also propose:

 task-distro-wifi-rdepends = "\
     wireless-tools \
-    hostap-utils \
+    ${@base_contains("MACHINE_FEATURES", "wifi", "", "hostap-utils",d)} \
     wpa-supplicant-nossl"

A machine with an internal hostap card could then add hostap-utils to
task-machine-wifi-rdepends in the machine configuration file.
(For hx4700 this variable would just contain kernel-module-acx and
kernel-module-hx4700-acx).

cheers
Philipp

Re: What is task-base?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pHilipp Zabel schreef:
> On 8/28/06, Marcin Juszkiewicz <openembedded@hrw.one.pl> wrote:
>> I think that we lack "serial" in MACHINE_FEATURES - this would be needed
>> by "irda" feature but will be also useful for machines which have normal
>> serial (RS232/RS485) here we can put lrzsz.
> 
> Are there machines that have neither serial nor irda?

my WAP54G for example :)

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFE+E2AMkyGM64RGpERAubQAKCn67Dxw5xaKAJp8Hqyh9XOLTVl7gCfT/5K
pQ+tpJZ5w1K5Pq+VRtY37l4=
=7mCl
-----END PGP SIGNATURE-----

Re: What is task-base?

[Marcin Juszkiewicz]

Today I added few sections into org.openembedded.documentation repository. 
One of them was about task-base and is available here:

http://www.openembedded.org/user-manual&dpage=ch04s04

I also wrote on my blog some stuff about it:

http://www.hrw.one.pl/2006/10/15/openembedded-documentation-day/

Have a nice reading.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

                 We are the Knights who say: MOVE.L USP,A1

Re: What is task-base?

[Paul Sokolovsky]

Hello Marcin,

Sunday, October 15, 2006, 4:44:27 PM, you wrote:

> Today I added few sections into org.openembedded.documentation repository.
> One of them was about task-base and is available here:

> http://www.openembedded.org/user-manual&dpage=ch04s04

> I also wrote on my blog some stuff about it:

> http://www.hrw.one.pl/2006/10/15/openembedded-documentation-day/


-----------
> TARGET_ARCH = "i686"
> IPKG_EXTRA_ARCHS = "x86 i386 i486 i586"
> 
> PREFERRED_PROVIDER_virtual/kernel = "linux-x86"
> 
> MACHINE_FEATURES = "kernel26 pci alsa usbhost"
> 
> require conf/machine/include/tune-athlonmp.conf
----------

   If it can be made so clean, why do we have so tangled configs for
many machines, at least for PocketPC-based? Do we need more strict
policy of what goes into machine configs and about the order of
variables? For example, I doubt it's good idea to have IMAGE_FSTYPES
in machine configs - how that can be machine's property? It's just
adhoc preference of conf author, which hardly will work for someone
another, so really should be set in local.conf.

   Also, it's good idea to group by some logical sections, for example,
machine properties rooted in hardware vs package selectors
(PREFERRED_PROVIDERs, etc) vs module autoload specification vs
something else.



> Have a nice reading.




-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: What is task-base?

[Koen Kooi]

Op ma, 16-10-2006 te 01:02 +0300, schreef Paul Sokolovsky:

>    If it can be made so clean, why do we have so tangled configs for
> many machines, at least for PocketPC-based?

Historical reason, and we'd welcome a cleanup

>  Do we need more strict
> policy of what goes into machine configs and about the order of
> variables? 

Yes :)

> For example, I doubt it's good idea to have IMAGE_FSTYPES
> in machine configs - how that can be machine's property? 

Some bootloaders can be quite demanding, like the one for the spitz
machine only likes tar.gz, not tar.bz2. It should be overridable,
though.

regards,

Koen

Re: What is task-base?

[Paul Sokolovsky]

Hello Koen,

Monday, October 16, 2006, 1:29:20 AM, you wrote:

> Op ma, 16-10-2006 te 01:02 +0300, schreef Paul Sokolovsky:

>>    If it can be made so clean, why do we have so tangled configs for
>> many machines, at least for PocketPC-based?

> Historical reason, and we'd welcome a cleanup

>>  Do we need more strict
>> policy of what goes into machine configs and about the order of
>> variables? 

> Yes :)

  Ok, to start with, I've reordered vars in h2200.conf & h4000.conf,
(plus moved weird-looking LAB setting to include file). Please tell me
if it looks ok, and I'll apply it to other files (pocketpc-based
devices at least).

>> For example, I doubt it's good idea to have IMAGE_FSTYPES
>> in machine configs - how that can be machine's property? 

> Some bootloaders can be quite demanding, like the one for the spitz
> machine only likes tar.gz, not tar.bz2. It should be overridable,
> though.

  Ok. But again, for any PocketPC one would use jffs2 for flash
install, tar.bz2 for secondary storage (card) install, ext2 for
initrd-like booting. As it is consistent for all devices, it can be
omitted from machine files, and controlled by distro and local.conf.
If there will be added support to build adhoc image reflash formats of
native pocketpc bootloaders, I agree, it is worth to add it
per-device, at least, as a kind of annotation.

> regards,

> Koen


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: What is task-base?

[Richard Purdie]

On Mon, 2006-10-16 at 00:29 +0200, Koen Kooi wrote: 
> Op ma, 16-10-2006 te 01:02 +0300, schreef Paul Sokolovsky:
> 
> >    If it can be made so clean, why do we have so tangled configs for
> > many machines, at least for PocketPC-based?
> 
> Historical reason, and we'd welcome a cleanup

Agreed.

> > For example, I doubt it's good idea to have IMAGE_FSTYPES
> > in machine configs - how that can be machine's property? 
> 
> Some bootloaders can be quite demanding, like the one for the spitz
> machine only likes tar.gz, not tar.bz2. It should be overridable,
> though.

Most of the Zaurus machines set that and its valid as the image type is
the one supported by the bootloader. Its not something I'd recommend in
general but makes sense there. (tar.gz for spitz, jffs2 for c7x0,
poodle, akita). After the machine sets it the distro and/or the user in
local.conf is free to alter or probably best of all append to the
variable.

Richard