Re: [Evolution-hackers] Understanding (and maybe cleaning) a11y library split in evolution



> you'd get a nice dependency loop in Makefile.

Welcome to the club. The circular dependencies between shared
libraries in e-d-s and evolution are "interesting". As you might
imagine some dirty hacks, er, I mean clever tricks[1], are needed to
work around the circular dependencies when building this stuff on
Windows, where there *can't* be unresolved externals in shared
libraries (i.e. DLLs)...

It would be really nice to cut down the number of shared libraries
built in e-d-s and evolution. I guess originally there might have been
some clean hierachy and separation of functionality behind the
plethora of shared libraries, but the situation has deteriorated quite
badly, with "components" depending on each others, "generic" libraries
depending on "components", etc. The ideal would be if one could build
e-d-s and evo also on Linux with the libtool switch -no-undefined
(making sure that it actually is enforced, possibly by also using the
ld switch --no-undefined or something)... Even though Windows in
general of course is quite braindead, in some respects it enforces
somewhat cleaner design... the ELF binary format is "too" forgiving
IMHO... but I probably am biased.

[1] Luckily, on Windows there is the concept of "import" libraries
which are what actually are used when linking, so the workaround is to
produce fake import libraries (referring to a DLL name that doesn't
exist yet) for bootstrapping purposes at first in the build, and then
link with those...

--tml


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