Re: RE: Initial patch for toolset modification proposal

"Gupta, Rita" writes...

> The initial thought behind this was to allow implementations to certify
> only for the "Core-core" libraries and not the Xt part i.e. Graphics.
> IMHO, it is OK to say that "default = Core + graphics + Cpp". For any
> subset, the -M approach may be used. Unless there are any objections...

Independent of what we do for certification, keep in mind that for 3.x that 
graphics is present, but starting in 4.x it will be moved to the desktop 
module. The tools packaging and functionality need to reflect that if we 
want to have the flexibility for developers to choose a la carte and to 
make certification changes. So that means the graphics headers and stub 
libs will need to be able to stand alone from the rest.(technically all 
modules should be able to stand alone)

When that happens should the default be based on if the lsb-desktop dev 
stuff is installed, or is that too confusing? I suppose it might surprise 
someone if the behavior changed just by installing new dev stuff.

If "default = Core + Graphics + Cpp" what should it do if the graphics dev 
files aren't available? (or Cpp for that matter, I suppose someone 
targeting just the core might not want that either)

Should this be controlled by a config file?

I think the easist answer to the above questions is to make "default = Core 
+ Cpp" and then have some way for the developer to easily adjust their 
environment to what that want (a config file, or have them to set an 
enviroment variable).

All of these application developers beating down our door, are the Desktop 
application developers or core?

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