Closed Bug 13509 Opened 20 years ago Closed 10 years ago

[feature] special typelib annotations for builddate and sourcefile

Categories

(Core :: XPCOM, defect, P4)

All
Windows NT
defect

Tracking

()

RESOLVED INCOMPLETE
Future

People

(Reporter: jband_mozilla, Assigned: dbradley)

Details

a big link of xpt files creates a file that is about one quarter full of
meaningless annotations
Assignee: mccabe → jband
Hardware: PC → All
Summary: xpt_link needs an option to disable creating annotations → xpt_link needs an option to enable creating annotations
reaasigning to me.
changed this from "option to disable" to "option to enable" - i.e. we just don't
generally need the annotation that is being written. This annotation just
says when the linker was run and what files were merged. I'm going to make the
annotation not get written by default.
Status: NEW → ASSIGNED
Summary: xpt_link needs an option to enable creating annotations → typelib annotations waste space
OK, I'm renaming this bug again to reflect the problem, not just a possible
solution.

"typelib annotations waste space"

A couple of points:

1) Why bother to save what we save: source idl filename, build date, interface
name list?

2) If we want to save some or all of this info then why in verbose text? We
could declare some tagged types of annotations (e.g. BUILD_DATE) and save the
binary data. Annotations are optional, but they don't need to be all text. We
can have xpt_dump know how to dump well known types of annotations.

3) If we are going to limit annotations it should be in the xpidl compiler not
xpt_link.

In my tree I added a '-a' option to xpidl that will make it emit annotation.
Otherwise it emits none. Is there a reason why we should not simply not emit
these annotations? I realise that if we want to acually use the option then the
Mac tool will need a change.

A note: libxpt and the the dumper were broken in that they didn't even
check to see if a typelib header might have zero annotations.

Who has opinions?
Generally agreed, but the typelib spec says that you have to have at least one
annotation:

tag

       The tag field discriminates among the variant record types for
       Annotation's.  If the tag is 0, this record is an EmptyAnnotation.
       EmptyAnnotation's are ignored - they're only used to indicate an array
       of Annotation's that's completely empty.  If the tag is
       1, the record is a PrivateAnnotation.

We should make a way for XPT_DoHeader to be told ``no annotations'' when it
restores as well, and save some CPU/memory.   That's probably another bug,
though.
[midair collision] Aha, I see that the typelib format requires at least one
single empty annotation. Fine.
...although we shouldn't crash if we have a typelib without one, and we probably
do.
Yup. The 8bit chunk with the 'last' flag is the minimum requirement. That's
fine.
I checked in these changes:

1) xpt_link now does not spit out its own meaningless annotation. And, it only
copies annotations from files if the first annotation is not empty (and marked
as the last annotation).

2) The xpidl compiler does not emit its (fairly) useless annotations anymore. It
*does* emit the required empty annotation marked as 'last'. I added a
commandline option to turn back on the old behavour at runtime if desired.

** The Mac compiler UI could add support for this option if desired **

I really think that if we want meaninful annotations then we should define some
flags for them and pack them in.
Summary: typelib annotations waste space → [feature] special typelib annotations for builddate and sourcefile
renamed from:
 "typelib annotations waste space"
to
 "[feature] special typelib annotations for builddate and sourcefile"

We could have tagged types of annotation records to tightly pack additional info
we might want to save rather than the humanreadable spacewasting annotations we
removed.
This bug has not been touched for more than nine months. In most cases, that 
means it has "slipped through the net". Please could the owner take a moment to 
add a comment to the bug with current status, and/or close it.

Thank you :-)

Gerv
mass reassign of xpidl bugs to dbradley@netscape.com
Assignee: jband → dbradley
Status: ASSIGNED → NEW
Target Milestone: --- → Future
Status: NEW → ASSIGNED
Priority: P3 → P4
Component: xpidl → XPCOM
QA Contact: mike+mozilla → xpcom
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.