[Lsb-infrastructure] new multi-version headers, Istandard, others

[Denis Silakov]

Wichmann, Mats D wrote:
> That's my excuse; the reality is I've been slow.
> Part of the issue is with these things getting so
> big and slow and my notebook at the same time 
> degrading in performance and reliability, it's no longer
> viable to use linux-in-vmware on the notebook as
> my primary development environment and when I traveled
> to the meetings this week I didn't quite get everything
> moved over that I needed.
>   
Well, we've never devoted much time to different generators performance.
So maybe it's time to spped up at least some of them. I do see some
places for mkheader to increase the speed by rather cheap modifications,
so we'll try to make it faster in future.
> I'm wondering if we are making the headers too
> compliated now.  Yes, the objective is not
> readability but functionality.  But... do we need the
> LSB 10 stanzas?  Can't we assume LSB 1.0 is a baseline
> and just not wrap the entire header in 1.0 conditionals?
> We could actually consider 1.2 a baseline because nothing
> before that was usable, but that's a different discussion.
> In other words, I feel like whenever the script wants to:
>
> #if __LSB_VERSION__ >= 10
> ...
> #endif
>
> it could just eliminate that, as this should be a given
> for an LSB header in the first place. 
>   
That's an idea, indeed.
> I know it means more script work, but it would be nice
> to eliminate the completely empty stanzas, and there seem
> to be quite a few of these... for an eample, the generated
> dirent.h has, very near the top:
>
> #if __LSB_VERSION__ >= 11
> #endif		// __LSB_VERSION__ == 1.1
>
> being a throwaway stanza, is this easy to just throw away?
>   
Not so easy, otherwise it would be already eliminated:) To be sure, it's
a known problem.
> It occurs to me that while the headers are now multi
> version for SDK usage, we haven't eased the problem of
> maintaing multiple build_env branches because the .def files
> are not multiversion (and they certainly should not
> be built with a bunch of ifdefs, it would make a very
> unattractive specification), because we may still
> have to generate updates for older specifications.
> I can imagine a case where we don't generate the .defs
> in exactly the same directory as the headers, but perhaps
> generate a set of version-specific def directories, or 
> possibly version-specific subdirectories, such as moving
> All to 4.0/All or All/4.0 and adjust the spec building to 
> pick up from that. Other than that, I don't have any thoughts yet.
>   
Agree, __LSB_VERSION__ inside spec text will not look nice.
Version-specific directories look good to me.

> My effort to regen the spec fell afoul of the change
> which moves Istandard out to the IntStd join table.
> I suspect changes were supplied for that and I didn't
> get them committed, this is the place where I should
> just wait until I have a connection so I can check the
> other files in ispras-lsb.  But anyway, I didn't get 
> to do this part of my review yet.
>   
I guess you should update files from
spidey:/srv/www/bzr/unofficial/ispras-lsb/lsbspec.
> On the trail of Istandard->IntStd, there have been
> several historical changes to the Istandard field,
> plus of course the Irefspec field is fairly new.  I
> assume we don't want to go back and try to reconstruct
> this historical data for older versions even though
> it means we can't exactly match older specs, but 
> thought I'd raise the issue anyway.  It wouldn't be
> too hard to reconstruct the 3.1 to 3.2 transition just
> by comparing those branches but further back would be
> challenging and probably not worth the payback.
>
> Also, I don't remember if we resolved the question 
> of changing spec names (mainly LSB itself which has
> a version number embedded at least somewhere, and I
> believe has changed over time) in the Standard table.
>   
Generally, we should have different entries for different spec versions.
We've discussed LSB to be a special case - we can leave the only one
record in the Interface table and simply adjust Navigator to provide
several links for interfaces that are present in several LSB versions.
> Final question, I'm wondering if there are plans yet
> for how we'll handle the versioning of stub libraries.
> Do we here also think about parallel directories,
> an extra level of subdirectory, etc?
Well, I actually don't see any other way except separate directory for
every LSB version.
> If any major
> mucking with the stub_libs scripts happens, is it
> possible to look at partial rebuilding, i.e. if I
> know I've made a change that only goes to libc, and
> I remove the libc stubs, could it regen just those
> based on missing targets?  Right now it's a broad
> stroke: you rebuild and it builds everything for
> every architecture, which has goten very slow; if
> we were to update this so it built everything for
> every architecture x 4 LSB versions, that would be
> unbearably slow for a developer (an overnight
> nightly autogen is a different story, but we can't
> wait for that if we're checking something specific
> as part of a review before committing a change).
>   
Yes, some work is required here. Actually, I don't see (at a first
glance) a reason for mkstublibs to work slow. So I'll check if it can be
accelerated, too.

-- 
Regards,
Denis.