Re: [Planner Dev] Windows Port - Status update

[Jani tiainen <redetin luukku com>]

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).

> > In my opinion static linking would be way to go, since views are pretty 
> > much essential parts of Planner and there are most likely not to be 
> > generated any third party views... This would also remove any 
> > backlinking issues that still exists in that simple library hack.
>
>
> 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.

Currently I have -export-(something) and of course it generates 
planner.exe.a library to be linked with. Very stupid issue with Windows 
is that it doesn't resolve symbols at runtime...

It also means that planner.exe must be built before any plugins. I did 
it by hand in my build (same issue exists with libplanner, it must be 
built before those file-modules otherwise they can't be built...)

--

Jani Tiainen