But what happens if it is /natural/ to embed something in the main Pascal source, which needs preprocessing in order to make it available as a resource etc.? The canonical example of this is embedded SQL.
If it would be with the yet to be integrated multiline string then it's just that: a string in an include file or the file itself.
If it would be with the yet to be integrated
$IncludeString directive then the included file in question would be handled like an ordinary include file as far as recompilation detection is concerned.
If it would be with the
$R directive to include a Windows-like resource then I can't answer whether this would currently work correctly. Ideally the compiler should handle changed resource files as well. What would definitely not work however is if you have a
$R something.res (meaning you use a precompiled resource instead of having the compiler generate it by calling
fpcres) and you change the original file that was compiled into the resource then FPC would have no way to detect that, cause the
res file contains no information about the original files.
I suppose that you could have a stub file that included both the definition and an implementation selected by conditionals, but that's getting /heavy/. My own opinion is that the copyright+license argument is significant, but separating the files also allows definitions to be locked against unauthorised modification
The stub file approach is in fact something that's used quite some time in the RTL
Since the wiki is basically annotating a non-public standard, and since "Standard" and "Extended" Pascal arguably did more harm than good to the language, I'm not at all sure that having keeping that page of "aspirational features" is in FPC's interest.
Extended Pascal was much less used than ISO Pascal, so it can't have done much bad. And sadly it came too late to unfold the good it promised (and if you take the time to read the Extended Pascal standard it has quite some goodies).
And keeping the page about the Extended is definitely in FPC's interest, cause it's about keeping track which features of Extended Pascal are already implemented. And while it's not a priority it
is our goal for FPC to also be a full ISO Extended Pascal.
Factual documentation of what FPC actually implements and what "standard" features it omits is obviously useful. A list of suggested extensions to the standards which can't be xrefed to the content of the actual standards isn't.
I agree. As such I have clarified on the Wiki that the part about the two-file-modules is merely a suggestion.
Edit: nearly forgot this:
To come back to your problem: as you see it should work correctly. However we know from past experience that something there is fishy when multiple include files are used, but we've not yet been able to pinpoint the problem. Or maybe it was indeed solved already. That's the problem: we don't have a reproducible case and thus don't know whether the problem has been solved or not.
Bearing that in mind, I think I'll try having separate .itf files when I've next got something I'm building as a library, and will also revisit the project I mentioned a few posts ago where stuff wasn't getting recompiled. I'll report back presently if I can pin a reliable test case down.
A reproducible test case would be very welcome.
There is this: https://gitlab.com/freepascal.org/fpc/source/-/issues/37478
This is about errors when using precompiled units. What I want is the compiler not detecting that something changed in indirectly used files and finishing successfully, but with no changes.