[fpc-devel] RTTI interface & variant late binding issue (mORMot)

[Marco van de Voort]

In our previous episode, Jonas Maebe said:

> > Indeed, but even leaving the very unpleasant license aside, depending on third party libraries
> > depending on libc is an issue on linux and an even bigger issue on windows not to mention rare
> > platforms like amiga or msdos.
> 
> Then these rare platforms can use something else, that's why I proposed
> a manager-style solution.

That is not a solution, it is moving the problem from you to target
maintainers who need to deal with the versioning problems and getting it
into distributions.

Just like you don't like maintaining multiple params, I'm not interesting in
gettting saddled with an perpetual pain because of dependencies.  Getting
recent versions to the user, by distribution or own compilation means is
hard enough.

So IMHO native solution for invoke, or just don't support it for the target
is good enough for me.

> And in spite of all the comments in the
> previous thread regarding cthreads/cwstring, I did not see a single
> point that argued that simply having a dependency on libc (especially
> via something as basic and portable as libffi) would cause problems
> other than for cross-compiling, even on Linux. It does not depend on
> particular versioned libc functionality, and this is not 199x anymore
> where even the name of the Linux (g)libc library was changed every full
> moon.

If the policy is abandonned, it should be done because sb invested time in
FPC_USE_LIBC solutions and guided the relevant targets through the change.

Then, with real feedback on issues a decision could be taken.

Such decision of a long standing policy should not be done because of some
immediate need of ffi.

Moreover, my ffi weariness is not just because it links to libc, but because
of the dependency and breakage of that package too. I don't feel like
managing this for such a little feature.
 
> Besides, many FPC programs for Linux already depend directly or
> indirectly on libc anyway via the LCL, cthreads, cwstring, clocale,
> database units and whatnot.

But do they distribute cross binary releases (like our .tar) that need to
be good for a while? 

I'm not against that, but it shouldn't be done rashly, and is unrelated to
the ffi yes or no.

> which was another misunderstanding raised in that previous thread; I'm
> just talking about making use of certain extra functionality used via C
> libraries).

No, you are also talking about having to manage those dependencies in the
release process. The release cycles are slow and complicated enough, I don't
need anything making it worse.

> What would be a pain is that every time I want to modify something to
> the implementation of the parameter manager, I would have to go through
> the RTTI dispatch code of all of our platforms to fix them up (because I
> know how frustrating it is to have your platform broken all the time if
> other people change things; that's also why I implemented the
> codepage-aware functionality for all platforms at the same time, or at
> least tried to make sure that those changes didn't break them).

If the FFI metadata changes you must massively update everything too, and
worse, existing releases are suddenly void for new distributions.
 
> - the libffi license is not GPL-incompatible. The requirement to ship
> the license with binaries is also in the modified BSD license, which is
> GPL-compatible per the FSF.

True.

> - Their "rtti" consists basically of integers of various sizes, arrays,
> structs (which are plain arrays of elements) and pointers. You can't get
> more basic than that, and we already have to convert everything down to
> that level inside the compiler anyway to map Pascal types to the
> official platform ABIs. It is nevertheless true that an API version
> change in libffi could break compatibility with existing programs, so
> you would have to ship libffi together with your program if you'd want
> to avoid that.

Pushing it on the user is IMHO a nono. They can barely manage building now.

> Just like I may not be sensitive enough to people's issues with external
> dependencies on some platforms, I'd like to ask other people to be more
> sensitive to the work required to add and maintain support for a
> particular platform in FPC (both compiler and RTL).

So don't do it. You effectively offer FFI as a crutch. Don't offer the
crutch, and keep it native or not on a per target basis.

If you can't afford to add a target just leave it and mark it as such in the
documentation.