Closed Bug 13509 Opened 20 years ago Closed 10 years ago
[feature] special typelib annotations for builddate and sourcefile
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 firstname.lastname@example.org
Assignee: jband → dbradley
Status: ASSIGNED → NEW
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.