RE: Proposal for toolset modifications for LSB-Desktoprelease

> -----Original Message-----
> From: Wichmann, Mats D
> Sent: Wednesday, January 04, 2006 4:54 PM
> To: Banginwar, Rajesh; [email protected]
> Subject: RE: [Lsb-test] Proposal for toolset modifications for LSB-
> Desktoprelease
> 
> Quick comments:
> 
> 
> >       For each of these tools we will add following command line
> >option:
> >       	--target | -T=[desktop,core] with core being
> >the default. So if
> >no option is specified, target will be set to core.
> >
> >-M option will remain for each of these tools to keep granularity if
> >needed.
> >
> >	e.g. lsbcc command line for desktop will look like: lsbcc
> >-T=desktop and for lsb3.0 there will be no change.
> 
> special case: I'm reluctant to use a command-line option for
> lsbcc as we don't know for sure what the back-end compiler will
> be.  In the case of gcc it doesn't currently appear to use
> the -T option, which is unusually lucky, but you could call
> a different compiler.  So we may want to handle lsbcc differently.

How about we just have --target and not -T. Will that make it better?
May be someone else will have another idea here.

> 
> How will we handle lsb-buildenv?
Same way. Lsb-buildenv -T=desktop start will be command line for
desktop. So we will just add a new cmd line option. Internally, we will
need to play some tricks in copying headers and stubs in /opt/lsb based
on the target.

> 
> >For Implementation:
> >Since we do not have LSB product table in the database listing all
the
> >modules for each product (core and desktop), we will hardcode the
list
> >of modules for each target till we fix the DB.
> 
> note that bug 1141 discusses this situation
> 
> >So for appchk, libchk the
> >implementation of -T option will be effectively mapping the tool to
> >concerned modules for that target. E.g. by default (target set
> >to core),
> >the tool will work on Core, C++ and Graphics modules; for desktop
> >target, it will work for Graphics-Ext, Gtk, Qt and XML modules.
> >
> >In LSB 4.0 timeframe I propose we add this new table describing cert
> >products and then the tools can be modified to remove the hardcoded
> >stuff.
> 
> on the whole, this looks resonable. it appears to address bug
> 1135 and others, which request some sort of product-level,
> rather than module-level grouping, now that the two are no
> longer identical (in fact, for core, they never were)
> 
> Thanks, Rajesh.
> 
> Let's see if we get a few more comments.