Re: Proposal for toolset modifications for LSB-Desktop release

"Banginwar, Rajesh" writes...

>        The goal is to avoid having separate version of this tool for
> desktop. Here is a proposal to address this problem (from user point of
> view)

I would also like to propose a goal:
The targets be defined by external files and not hard coded into the tools 
or dependent on something the LSB issues as part of a release. My goal with 
this is that the tools shouldn't need to new release to add support for a 
new target. I'm thinking that to add new targets you drop a file into 
$PREFIX/lib/lsbfoo/targets/ or something and that file defines the new 
target. So if this is done correctly then the 3.1 versions of the tools 
won't have any desktop information in them at all but just the ability to 
load these target resource files. Then when the desktop release happens to 
support it all you need to do is drop in the right files and presto it 
works. This will allow us to add additional targets or even for third 
parties to add targets without needing changes to the tool.

>        	--target | -T=3D[desktop,core] with core being the default. So 
> if no option is specified, target will be set to core.

wondering out loud here...
desktop is dependent on core, and nearly all modules will be dependent on 
core, but I think we might eventually have targets that are dependent on 
other targets and maybe not even dependent on core? I don't know if we have 
to support that right away, right now we can just require the targets to 
flaten those dependencies out by hand. If we use the target definition 
files I mentioned about I guess it would be nice if one could include 
another, but probably won't be needed right away.

> -M option will remain for each of these tools to keep granularity if
> needed.

Cool.

> 	e.g. lsbcc command line for desktop will look like: lsbcc
> -T=3Ddesktop and for lsb3.0 there will be no change.

... since core is the default and we haven't moved the X libs and OpenGL 
out of core yet. But the 3.1 version of the tool will know about the -T 
flag right?

Then once we get to LSB 4.0(with the second release of desktop), the X libs 
and OpenGL will be moved to desktop, and core will still be the default for 
the tools but no longer include that stuff. Sound right?

> For appchk: we currently have -A option to enable all modules. I propose
> to remove that option.

I agree.

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

As stated above I would prefer this happen sooner, but I'm not the one 
doing the work so....

-- 
Matt Taggart        Open Source & Linux Organization R&D
[email protected]   Hewlett-Packard