[fpc-devel] Delphi-like Packages, Plan

[Dimitri Smits]

----- "Willibald Krenn" <Willibald.Krenn at gmx.at> schreef:

> >> Willibald can get access to a branch to commit his work.
> > Also an idea. But you might outline some rules for commits so that
> not
> > the same problems happen as with DoDi's branches.
> 
> A branch would be nice, I guess. So everyone had a chance to see what
> I 
> am doing. Just to be clear about my intensions: I don't want to change
> existing code. Only if there is no other way I will introduce changes,
> but these will be minimized as much as possible.
> 

maybe others want to contribute too. Will this be a Willibald-only branch?

[OT]
one showstopper (besides loads of time) I have is getting the fpc-trunc to compile and create a specific bin folder. 
as far as I've gathered is that you need to do a "make clean all" and then copy all the resulting exe's to somewhere (find and retrieve yourself strategy). But all those configuration files etc that you get with a binary release download are a mystery to get right.
[/OT]

if I got this to work, then I'd be happy to volunteer some time on that branch as well.

>  > dcp can also contain implementation part of .dcu which is .o in
> FPC.
> 
> Yes, they probably do. For the beginning (and with generics in mind) 
> it's probably easier if they do.

don't forget "inline" as well, not just generics.

> Regarding M1
> ============
> 
>  >If you want this TPackageModule or whatever in system.pp (e.g in the
>  >RTL, not in the compiler) you should use records, because objpas.pp
> is 
>  >not loaded inside system.pp (and thus TObject isn't available).
> 
> Good to know. Actually I hope I can hide the package-thing from the
> RTL, 
>   which probably is a bit unrealistic ;-). Well, at least for M1 I'll
> 
> concentrate more on compiler internals than RTL aspects.

you'd have a bit more dependency-hell when you want to make your LoadPackage/UnloadPackage methods and need to either re-implement the dynamic-lib loading or use the standard x-platform one.

also: TPackagemodule should indeed better be a record (maybe have a look at versions beyond D7, to TLibModule for instance)

Which reminds me: ALL your build-targets should register their contents through packagemodule and consorts. That means the main exe or shared-lib as well. Otherwise it is impossible to detect duplicate units and double-initialisation and other troubles with the runtime linking.

A tree-structure emerges in the newer delphi's: Module - unit - types
A module contains x units
A unit contains y types

careful for smartlinking those structures.

> Regarding M2
> ============
> 
>  > What do you want to mangle here? [RTTI]
> 
> RTTI for types needs to be exported, so it needs to have a name. I
> don't 
> know yet whether there already is one.

I think you mean replacing "RTTI_" with "@xp@" or something you are more familiar with for starters?
RTTI is already provided. Try building with retaining assembler output to see what I mean.

Some link-names are indeed easily becoming too long, others would think the "all uppercase" is unneccecary. I'd say they are there, they work and were the personal taste of the core-team biased to it through experience and other arguments.

kind regards,
Dimitri Smits