[fpc-devel] Delphi-like Packages, Plan

[Willibald Krenn]

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

I surely don't mind fellow contributors (au contraire!!) - if we agree 
on some partitioning of the work and one common plan. For example, it 
would be terrific, if someone could do Linux or Win32 as main platform. 
And with time, more and more opportunities for contribution will emerge, 
as all the RTL stuff needs to be implemented....


> [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]


Well, I too had difficulties getting fpc to compile (with -gl). First 
thing, you need the FPC 2.4 compiler and then do  e.g.,

make clean build install PP=fpc CPU_TARGET=<?> OS_TARGET=<?> DEBUG=1 
OPT="-gl <whatever>" UPXPROG=echo COPYTREE=echo  INSTALL_PREFIX=<install 
path> FPC=<path to fpc for bootstrap>

(should be one line). At least that command works for me. BTW, you'll 
need the mingw files that come with the 2.4 install. This being done, 
you can use lazarus to do the development and debugging.

Beware: On Win64 gdb 7.2 will crash when you raise an exception. This 
_might_ be caused by the non-Win64-standard exception mechanism FPC uses.


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

Welcome! :)

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

Yep. (For inlined methods/functions we could - theoretically - provide a 
'non-inlined' version in the binary package....)

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

I don't want to re-invent or re-implement things. :)

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

Ok, never had a look at D7+. There however is a difference between the 
metadata found in a bpl and the dcp. First thing I'd say should be 
accessible via some record-type defined in the rtl, latter is some 
compiler-internal thing (and the TPackagemodule I was referring to).

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

Sure. However, I'd have said that this is more of an M1.5 to M2 type of 
thing. First I'd like to see what changes need to be incorporated in the 
compiler to get the very basics done. Afterwards all the stuff on the 
RTL needs to be added.

On a side note, I've seen that we need to check/change/extend the 
_DLLMainCRTStartup (etc.) functions which should probably behave 
different in a package than in a dll.


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

Hmm, I still have to think about smartlinking and packages. Is there a 
way to use smartlinking when compiling a package?

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

Very well, then we just need to include that symbol in the 
exports/imports section.


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

I really don't care about how names are mangled. If it works, we will 
use it. As already said, I'm not into a rewrite of the compiler *g*. I 
just want to use packages ;).


Cheers,
  Willi