[fpc-devel] RTTI unit

[Michael Van Canneyt]

On Sun, 29 Aug 2010, Dimitri Smits wrote:

>
> Michael, thank you for the reply. It makes a few things a lot clearer for me. I'll comment a bit more below.
>
>>>
>>> For this I'd like to know a few things:
>>> - First off: would this kind of thing even be considered for
>> inclusion?
>>
>> Yes. Any unit to increase Delphi compatibility is worth of inclusion.
>
> good to know. to be placed next to types unit in objpas, I presume.

Yes.

>
>>> - How to get it into repository/feedback from core? (through feature
>> request with attachment in mantis?)
>>
>> I'll handle that; Just post it on mantis, I'll look into it.
>
> attach the unit, or in patch form?

Attach the unit to your mantis bug report.

>
>>> - Codestyle conventions for fpc-code? (including licence-header
>> etc)
>>
>> Modified LGPL header (see any rtl file).
>> Code style: follow the Borland style guide.
>
> that header, with your name & Florian or mine or 3? :-)

Just put "FPC team" or so.

>
>>
>>> - Is there (besides System, SysUtils, Types and the Variant-units)
>> another place to look for RTTI-types?
>>
>> Not sure I know what you mean by this ?
>
> Is there another unit other than those that contains structures & defs
> mapping to what the compiler generates?  (like ptypeinfo, but also for
> punittype, or packages)
>
> anything I've missed regarding lowlevel info on types & language constructs

There is nothing; the typeinfo unit contains most info apart from the compiler sources.

>
>>
>>> - Where do I need to take care off (how to include it in rtl
>> package, ..., unit-dependencies )?
>>
>> Nothing. I'll take care of that, you just write the code.
>>
>
> what i meant was: don't use generic types like fpglist and/or consorts
> that are not in the rtl package.  (what files can I check to see what is
> included in the rtl so I don't accidentally make cyclic dependencies.

No generics, please. Generics are highly beta. 
Apart from that, I don't think there are any caveats.

>
>>> - I've read somewhere that nothing gets included if no unit-tests
>> are
>>> - provided.  Is this using fpcunit?  Any pointers on the
>> testingsystem,
>>> - do's and don'ts are welcome.
>>
>> You can use fpcunit; there are sample tests in the fcl-fpcunit
>> directory.
>>
>
> to be placed under what dir? fpcunit would have been my choice nevertheless. :-)

We'll see.

>
>> All other daily test programs use a different mechanism: they must
>> return
>> a zero exit code. Nonzero exit code means that there is an error.
>>
>> You're free to choose one over the other; Personally, I favour
>> fpc-unit style.
>> I find it works most easily, definitely if you use Lazarus.
>>
>
> so, lpi files and the like are acceptable in fpc?

Insofar as they contain only non-visual code. No dependency on the LCL.
The .lpi file should just enumerate the dependencies of your pogram;
session info should be in a separate file, which is not committed to SVN.

>
>>> Since I work on win32 (only), I'm not that familiar with makefiles.
>> So, if
>>> I need to add anything to makefiles or copy+edit another makefile,
>> please
>>> redirect me to more information.  (mainly for testing-app, I guess)
>>
>> Let me handle that. Focus on the code.
>>
>
> will do. Have to start, and probably will go through a few iterations
> before I post it in mantis (also, when time permits).  And even then it
> might be something to discuss first and take a few posts to get it
> "feature complete".
>
> if that's allright by you ;-)

Of course.

Michael.