RE: 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 will we handle lsb-buildenv?

>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.