On 4/17/26 4:32 PM, Graeme Geldenhuys via fpc-devel wrote:
On 2026-04-17 13:00, Marco van de Voort via fpc-devel wrote:
And then we still have to find out if that concept works at all in
the FPC context.
And yet it works flawlessly on 10,000s of other open source projects
(big and small). I simply don't know why you think FPC is so special
that it will not work here.
FPC is special in the regard that it is a compiler and that it has an
extremely high coupling between compiler and rtl units. So, changes are
very interdependent. It's hard to separate them and treat them as
independent, because they're simply not. This doesn't apply to most of
the packages. That's why there's extra effort on keeping the compiler's
history linear, avoiding merge commits and running regular automated
tests on many platforms, so that bugs are caught early and so that it is
easy to find the single commit that caused a bug via "git bisect". I've
worked commercially in my last job on a compiler for a specialized
language, called "Noir" that used a "squash" all merge request policy
and it didn't work well with regards to stability and ease of resolving
merge conflicts. But it was a "move fast and break things" kind of
startup mentality, so they didn't care much about stability at this stage.
Nikolay
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
