Re: [Planner Dev] Windows Port - Status update



On tor, 2004-07-29 at 22:33 +0300, Jani tiainen wrote:
> Richard Hult wrote:
> 
> > On tor, 2004-07-29 at 21:35 +0300, Jani tiainen wrote:
> > 
> > 
> >>Well this seems hard to spot, since it goes to Windows internal 
> >>libraries and there you end up with nothing, so I have to do it hardway 
> >>- step until something appears. =)
> > 
> > 
> > Hm, even a stacktrace doesn't give anything? It should tell you where
> > the code is being called from...
> > 
> > 
> >>Now I have had decent sleep and given second tought about how views can 
> >>be implemented... I really don't want to do any temporary library hack. 
> >>So this leaves two options, use GModuleType, or static linking. Which 
> >>one I should go for?
> > 
> > 
> > The views could at some point be compiled in, but if just fixing the
> > build means less changes, I prefer that at this stage.
> 
> Well I did fixed build plus I had to change that re-registration 
> stuff... It might be solved with just building extra library and link 
> against it, but I don't see it valuable, it's just a hack and I rather 
> avoid any hacks, it will generate just problems (and makes compiling a 
> lot slower than it currently is).

What specific problems are you referring to here?

Generating one more library consisting of a few files can't possibly be
noticeably slower, can it?

Also, why is it a hack? IMO, it's the correct way to setup those two
views since the shared types must be same code instead of two versions
of the same code. It's more or less sher luck that it works on linux,
the runtime linker probably disregards the second copy of those
functions or something like that.

> > Are you sure that it's not possible? It sounds like a terrible
> > limitation, how could any plugins ever work in any app? Are you sure
> > it's not just a matter of adding -export-dynamic to the planner
> > executable LDFLAGS? (plus splitting the shared files from gantt/task to
> > a helper lib).
> 
> Well it's possible, since I had to do it for current version. Only issue 
> with current version is re-registering objects that could be resolved on 
> portable way by using GTypeModule class.

If we split out the shared task/gantt code, the re-registration guard
shouldn't be necessary anymore. (At least that's what I expect, since
the static variables holding the type will be the same instance, instead
of one separate per view.)

/Richard

-- 
Imendio HB, http://www.imendio.com/




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]