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

[Jonas Maebe]

On 07/02/15 19:01, Marco van de Voort wrote:
> 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.

It is not "moving the problem", it's at most changing one problem into a
completely different one. And libffi is probably already in all
distributions, because it's used by a.o. CPython and OpenJDK.

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

That is however unacceptable to me. If it is considered basic
functionality (which RTTI is, afaik), then it must be implemented for at
least all main targets.

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

I explicitly mentioned later on that I did not argue in favour of making
the entire RTL libc-based. I'm talking about the rule that nothing at
all can depend on libc whatsoever.

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

There have been cthreads, cwstring and clocale before. And there will
undoubtedly be more in the future. And as mentioned, a manager approach
is fine by me.

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

I don't feel like reimplementing and mainting the parameter manager in
the RTL for "such a little feature" either.

>> 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? 

The compiler wouldn't depend on libffi if it's implemented via a
manager, because the compiler itself won't make use of that
functionality. Should it ever do so anyway, we'll cross that bridge when
we get there (although I can't immediately think of a practical scenario
where we would want to do that). Someone could even implement an
"fplibffi" then if they'd want to, like fpwidestring.

>> 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,

No, that's my main point: even if that would happen, then you only have
to update things in one place (the mapping from our generic RTTI to
libffi's generic parameter description). While if things would change in
the compiler when you have a Pascal implementation for every platform,
then you possibly have to change this Pascal implementation for every
platform.

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

"The user" already has to deal with this for every single Lazarus program.

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

Using a library as intended is not a crutch.

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

Which won't confuse or annoy users at all...


Jonas