[M3devel] unnecessary relinks when import libs change

[Jay]

Granted, just given a file path and a timestamp -- don't know if it is an import .lib or not.
Either takes more smarts on the consumer, or I think more likely, more smarts on the producer.
At least on Windows, the .objs within an import .lib are easily discernable as the special import type and not containing static code. You can actually have hybrid .libs. For example msvcrt.lib contains mostly imports but also static startup code (thus no need for crt0.o or such). Anyway, I think the smarts belong in the producer as that is what would lead to less i/o.
 
I'm starting to need a bug database. :)
 
e.g. cleanup this redundancy:
 C:\dev2\cm3.2\m3-mail\postcard\src\UtimeExtra.i3(31):<*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star; C:\dev2\cm3.2\m3-mail\webcard\src\OSUtils.m3(226):      tm := localtime(ADR(secs))^ C:\dev2\cm3.2\m3-mail\webcard\src\UtimeExtra.i3(31):<*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star;
(make ANSI time.h available on Win32 also, if it helps)
 
 - Jay



> Date: Sat, 23 Feb 2008 16:27:59 +0100> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] unnecessary relinks when import libs change> > I think cm3 reacts conservative if an imported library changes> because programs may be built standalone. A possible optimization> would be to check if the symbols are still the same (as you suggested)> and avoid the re-link in case of building shared (but not if building> standalone, as the symbols may be the same, but the code has changed).> > Olaf> > Quoting Jay <jayk123 at hotmail.com>:> > > I see a lot of like:> >> > == package C:\\dev2\\cm3.2\m3-obliq\synloc == +++ ['cm3.exe -build > > -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 > > -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm', > > 'cm3.exe -ship -keep -DROOT=/C/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.6.0 > > -DCM3_VERSION_NUMBER=050600 -DCM3_LAST_CHANGED=2008-01-31 @M3novm'] > > +++> > --- building in NT386GNU ---> >> > ignoring ../src/m3overrides> > new "/C/cm3/pkg/libm3/NT386GNU/m3.lib" -> archiving synwr.lib > > *** This line ****mklib -out:synwr.lib SynWr.io SynWr.mo > > SynLocation.io SynLocation.mo 2>&1 > synwr.lstgcc -shared > > -Wl, at _m3responsefile1.txt 2>&1 > synwr.lstCreating library file: > > synwr.lib--- shipping from NT386GNU ---> >> > This is mildly dumb.> > I should check as to why m3.lib changed, but an import .lib changing > > is rarely legitimate cause for a relink.> > As long as no symbols were added or removed, no relink is needed.> > Even then, it usually doesn't matter, but harder to tell.> >> > It's true the import .libs have "hints" as to "ordinals" but I don't > > think anyone cares about those.> >> > Definitely maybe the fix should be that when the import .lib is > > made, if the list of symbols exported is identical to the previous > > version, don't update the file.> >> > - Jay> > _________________________________________________________________> > Connect and share in new ways with Windows Live.> > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080223/65248404/attachment-0002.html>