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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
