The SourceForge fpcext project <http://sourceforge.net/p/fpcext/home/> shall allow to customize and extend the FPC compiler, with e.g. alternative components and languages.

After some tries I got at least the git repository work, but I'm not sure whether I did it the right way. The repository shall track the SVN trunk, so that no bugfixes or other improvements get lost.

Currently branches exist for the preprocessor and alternative parsers, where the parser branch will include some FPDoc documentation of the compiler (to come). Alternative parsers shall include an alternative OPL parser, using separated semantic objects and procedures, a modula-style variation of the OPL syntax, with statement-sequences, and an Oberon-style parser.

The scanner has been made virtual, so that parsers and scanners for alternative languages can be possible
modifications are fully memory based source files, which may speed up parsing and compilation.

Contributions, suggestions and discussions are welcome, the technical details have to be worked out. Possible topics are the use of AnsiStrings, alternative hashtables and file/directory caches, and of course the still missing refactoring of the ppu file loader/management and register allocator. These are only suggestions, not a closed on-topic list.

DoDi

Hans-Peter Diettrich wrote

The SourceForge fpcext project <http://sourceforge.net/p/fpcext/home/> shall allow to customize and extend the FPC compiler, with e.g. alternative components and languages.

Are you sure you do not want to use Github?

Alexander Klenin wrote

Are you sure you do not want to use Github?

There is nothing wrong with SourceForge.net't git setup, it works just as good as GitHub. The benefit of SourceForge is that they give you plenty of other "project related tools" too. eg: a location for a website, various bug trackers, wikis, mailing lists etc etc... So for overall project management, SourceForge is a much better choice.

Just encountered a problem: when I add FPDoc documentation, currently residing in compiler/docs/, the content should be available in all branches, updates should not be affected by checking out other branches.

Questions to the gurus:

How can I add this directory to the git repository, so that it is available as a self-contained project/branch?

Since most of the (current) documentation applies to FPC in general, where should such documentation reside, in the (SVN) directory tree? How to separate general docs from branch-related docs?

DoDi

Hans-Peter Diettrich wrote

How can I add this directory to the git repository, so that it is available as a self-contained project/branch?

SourceForge.net allows unlimited git repositories per project. Each repository is stand-alone, but under the same "sourceforge project". Not sure if this is what you want, but there is another option. I think it's called "git modules", where you can have multiple repository working together in one hierarchy. I have no idea how to set this up though, I have never used that feature. I know KDE project does. Just read the git docs, they should explain it there.

Hans-Peter Diettrich wrote

How can I add this directory to the git repository, so that it is available as a self-contained project/branch?

Why not fork the branches after these files are added ? I suppose GIT allows to add them in a way that they appear as if they would have existed before branching.

-Michael

I managed to create two projects, for the compiler/ and compiler/docs/ directories. Unfortunately these are not shown in the SF page, but they should be accessible as
<git://fpcext.git.sourceforge.net/gitroot/fpcext/docs> and
<git://fpcext.git.sourceforge.net/gitroot/fpcext/compiler>

The separate compiler project allows to have an playground either inside or outside the fpc directory.

Tracking of the SVN repository seems to be somewhat tricky, in detail on Windows, due to line-endings. So I finally gave up to track the SVN updates myself, and checked out Graeme's fpc repository at <git://github.com/graemeg/freepascal.git>. In that directory I created a new git repo, in the compiler/ subdirectory
git init compiler
and added the above .../compiler external repo to it.

The same for the docs directory, that can reside anywhere (in theory), but the FPDoc Editor requires that all documented files reside in a package. So I added such a package to the docs, what requires that docs/ is a subdirectory of (any) fpc/compiler/ directory.

When the compiler project resides inside an fpc working directory, be SVN or Git based, care must be taken to sync both checkouts. For that purpose I added several SVN versions to the trunk branch, and intend to rebase the branches on newer SVN revisions, from time to time. A user will have to checkout the common base revision from the fpc repo first, then checkout the desired branch from my compiler repo. When you use Graeme's repo (recommended), look at the SVN revision number in the commits, in order to checkout the required version. If somebody knows about easier procedures, please let me know...

The compiler repo currently contains the branches:

trunk - fpc base revisions
preprocessor - make the PREPROCWRITE code work
AltParser - allow for alternative parsers (includes ParserOPL) Oberon - an Oberon/ComponentPascal parser, on top of AltParser AltScanner - a scanner caching entire source files in memory (to come)

The docs repo only contains one branch, and does not rely on a specific SVN revision.

The original fpcext repo should not be used, it has too many flaws from my first steps into the world of multiple repositories on SF :-(

DoDi