[fpc-pascal] Resource compilation

[Martok]

Hi all,

the $R directive accepts resource scripts (RC) and compiles the RES file from it
on demand.

However, that only happens if the RES file does not exist - if it does, the
resource compiler is never invoked. Even clean-building the unit from source
does not recompile the resource file. This is a bit awkward when the resource
script (or any of the linked files) is changed: the only way to recreate the
resource unit appears to be removing both the compiled unit and resource file.

Is there some sort of flag for this? I'd be fine with just recompiling the
resource file every time the unit is compiled, windres is fast enough...

Thanks,
Martok

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mai

[Graeme Geldenhuys]

Post by Martok
the $R directive accepts resource scripts (RC) and compiles the RES file from it
on demand.

Also note that that is only true for Windows. FPC doesn't include a
resource compiler for any other platforms. So if no resource compiler
exists, you will get a compilation error until you make other plans.
Another FPC limitation that really should be resolved.

Regards,
Graeme

[Sven Barth via fpc-pascal]

Post by Graeme Geldenhuys

Post by Martok
the $R directive accepts resource scripts (RC) and compiles the RES file from it
on demand.

Also note that that is only true for Windows. FPC doesn't include a
resource compiler for any other platforms. So if no resource compiler
exists, you will get a compilation error until you make other plans.
Another FPC limitation that really should be resolved.

You are aware that FPC supports resources on basically all platforms?
After all it was introduced for Lazarus back before 1.0 or so.

Regards,
Sven

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cg

[Graeme Geldenhuys]

Post by Sven Barth via fpc-pascal
You are aware that FPC supports resources on basically all platforms?

I know that. What I meant is that FPC only ships with a Windows resource
compiler - ability to compile RC files to RES files. All other platforms
you have to find your own Resource Compiler. So on a clean system with a
fresh FPC install, only under Windows will you have the ability to
compile source code that references .rc files.

Regards,
Graeme

[Sven Barth via fpc-pascal]

Post by Graeme Geldenhuys

Post by Sven Barth via fpc-pascal
You are aware that FPC supports resources on basically all platforms?

I know that. What I meant is that FPC only ships with a Windows resource
compiler - ability to compile RC files to RES files. All other platforms
you have to find your own Resource Compiler. So on a clean system with a
fresh FPC install, only under Windows will you have the ability to
compile source code that references .rc files.

Because it's only Windows that we provide a setup for. If someone would
provide an FPC implemented resource compiler we'd include it.

Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal

[Graeme Geldenhuys]

Post by Sven Barth via fpc-pascal
Because it's only Windows that we provide a setup for.

Huh? I've been downloading the official FPC console installers for
FreeBSD and Linux since 6 years ago. I never use distro packages
managers for FPC.

Regards,
Graeme

[Giulio Bernardi]

I think that what Sven meant is that fpc's Windows installers include binutils,
while this is not true for other platforms: that is, you need to have ld on your
system if you want to use it as a linker, fpc does not provide it.

Same as for windres: if you need it, usually you can install it from mingw's
binutils. In fedora I can install it from mingw32-binutils (or mingw64-binutils).
I see that a package with the same name also exists in FreeBSD, so I assume it
will contain windres as well.

https://www.freshports.org/devel/mingw32-binutils/

Giulio

Post by Sven Barth via fpc-pascal
Because it's only Windows that we provide a setup for.

Huh?  I've been downloading the official FPC console installers for FreeBSD and
Linux since 6 years ago. I never use distro packages managers for FPC.
Regards,
  Graeme

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.f

[Sven Barth via fpc-pascal]

Post by Giulio Bernardi
I think that what Sven meant is that fpc's Windows installers include binutils,
while this is not true for other platforms: that is, you need to have ld on your
system if you want to use it as a linker, fpc does not provide it.

Exactly.

Regards,
Sven

[Graeme Geldenhuys]

Post by Sven Barth via fpc-pascal

Post by Giulio Bernardi
system if you want to use it as a linker, fpc does not provide it.

Exactly.

Exactly my point! Why? Why does the official FPC installer for Windows
give a more workable solution out of the box (1), but official
installers for other platforms don't?

And please don't tell me the usual "Delphi compatibility" for G*d sake.


1. Ability to compile source code with .RC reference and magically
compile those to .RES as needed.


Regards,
Graeme

[Sven Barth via fpc-pascal]

Post by Graeme Geldenhuys

Post by Sven Barth via fpc-pascal

Post by Giulio Bernardi
system if you want to use it as a linker, fpc does not provide it.

Exactly.

Exactly my point! Why? Why does the official FPC installer for Windows
give a more workable solution out of the box (1), but official
installers for other platforms don't?

Because on non-Windows systems (especially the *nix ones) we rely on
their package distributions systems and it's up to the package
maintainers to set up the packages accordingly for their distribution so
that they pull in the required packages. Such a system does not exist on
Windows however so we bundle everything there.

Regards,
Sven

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman

[Martok]

Post by Graeme Geldenhuys
Also note that that is only true for Windows. FPC doesn't include a
resource compiler for any other platforms. So if no resource compiler
exists, you will get a compilation error until you make other plans.

AFAIK, windres is available for lots of other platforms. If you have to install
some package, that shoud not really surprise a developer?
I would assume that FPC just tries to call a resource compiler on all platforms
and fails with some error message if it isn't available?

If so, I wouldn't worry too much about having our own resource compiler. The RC
script language is actually quite complex, and there'd be next to no benefit to
reinventing the wheel.

--
Martok

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://

[Graeme Geldenhuys]

Post by Martok
If so, I wouldn't worry too much about having our own resource compiler. The RC
script language is actually quite complex, and there'd be next to no benefit to
reinventing the wheel.

The same could be said about implementing a competing (alternatives to
C/C++ or Delphi) compiler. ;-) Yet FPC project took up that challenge.

Regards,
Graeme

[Martok]

Post by Graeme Geldenhuys
The same could be said about implementing a competing (alternatives to
C/C++ or Delphi) compiler. ;-)

Not really though ;-)
Rewriting a resource compiler with the same input and output files as the
existing one is a bit different than writing a compiler for a new language and
targets...

However, it seems that for example in Debian, windres is only in the
crossbinutils package? That's not quite what I expected...
What we really need then is "only" a parser frontend for fpcres, fcl-res already
can do all the writing we might ever need. Could someone please check if there
exists an issue for it and if not, report it? Might have a poke at it, but I'll
probably forget before having the time ;-)

--
Martok

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailm

[Sven Barth via fpc-pascal]

Post by Martok

Post by Graeme Geldenhuys
Also note that that is only true for Windows. FPC doesn't include a
resource compiler for any other platforms. So if no resource compiler
exists, you will get a compilation error until you make other plans.

AFAIK, windres is available for lots of other platforms. If you have to install
some package, that shoud not really surprise a developer?
I would assume that FPC just tries to call a resource compiler on all platforms
and fails with some error message if it isn't available?
If so, I wouldn't worry too much about having our own resource compiler. The RC
script language is actually quite complex, and there'd be next to no benefit to
reinventing the wheel.

The RC language itself isn't *that* difficult. Main difficulty would be to
essentially implement a C-preprocessor-compatible preprocessor.

Regards,
Sven

[Martok]

Post by Sven Barth via fpc-pascal
The RC language itself isn't *that* difficult. Main difficulty would be to
essentially implement a C-preprocessor-compatible preprocessor.

As I have just discovered, the installer provides a (rather antique) gcc on
Windows and depends on build-essential on (all?) *nix platforms, so we don't
even need to do that - piping through "gcc -E -xc" should be all we need.
That just leaves a reader for fcl-res.

Hm.

[Sven Barth via fpc-pascal]

Post by Martok

Post by Sven Barth via fpc-pascal
The RC language itself isn't *that* difficult. Main difficulty would be to
essentially implement a C-preprocessor-compatible preprocessor.

As I have just discovered, the installer provides a (rather antique) gcc on
Windows and depends on build-essential on (all?) *nix platforms, so we don't
even need to do that - piping through "gcc -E -xc" should be all we need.
That just leaves a reader for fcl-res.

The point of our own resource compiler would be to avoid external
dependencies. While me might ship with a gcc on Windows I nevertheless
consider it as an external dependency and thus a preprocessor written in
Pascal would be preferred.

Regards,
Sven

[Martok]

The point of our own resource compiler would be to avoid external dependencies.

True. And having a general-purpose preprocessor would come in useful anyway.

Fun fact: windres also just calls gcc, which is probably why we deploy it:
#define DEFAULT_PREPROCESSOR "gcc -E -xc -DRC_INVOKED"

But it would be a replacement of a somewhat obscure dependency (windres seems to
be a crossbinutils thing) with just keeping a standard one.

--
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/

[Martok]

The RC language itself isn't *that* difficult. Main difficulty would be to essentially implement a C-preprocessor-compatible
preprocessor.

Just "a few" months later, I finally got around to checking this out.

You were completely right, the language itself is not very difficult, and can be processed into a TResource in one pass in a
tply-generated parser. The preprocessor is also just a subset of C's (i.e.: no macros), so it would not be too complicated (I've
done the same for idlproc before). There are dialect issues between windres and Microsoft RC, but they are minor.

The more difficult part is implementing the remaining resource access classes for fcl-res. Well, not difficult per se, but the
copy-on-write-sharing thing done there adds a lot of complexity for (IMHO) very little benefit and makes it a bit awkward to
work with. There's also a lot of endian conversions that could probably be factored out.

That sounds challenging. How much interest would there be in having a full resource compiler, with the appropriate
changes/extensions to fcl-res?

[Michael Van Canneyt]

Post by Martok

The RC language itself isn't *that* difficult. Main difficulty would be to essentially implement a C-preprocessor-compatible
preprocessor.

Just "a few" months later, I finally got around to checking this out.
You were completely right, the language itself is not very difficult, and can be processed into a TResource in one pass in a
tply-generated parser. The preprocessor is also just a subset of C's (i.e.: no macros), so it would not be too complicated (I've
done the same for idlproc before). There are dialect issues between windres and Microsoft RC, but they are minor.
The more difficult part is implementing the remaining resource access classes for fcl-res. Well, not difficult per se, but the
copy-on-write-sharing thing done there adds a lot of complexity for (IMHO) very little benefit and makes it a bit awkward to
work with. There's also a lot of endian conversions that could probably be factored out.
That sounds challenging. How much interest would there be in having a full resource compiler, with the appropriate
changes/extensions to fcl-res?

I think a lot. There is a request in the bugtracker for a resource compiler since ages.

Michael.

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/

[Sven Barth via fpc-pascal]

Post by Martok
Hi all,
the $R directive accepts resource scripts (RC) and compiles the RES file from it
on demand.
However, that only happens if the RES file does not exist - if it does, the
resource compiler is never invoked. Even clean-building the unit from source
does not recompile the resource file. This is a bit awkward when the resource
script (or any of the linked files) is changed: the only way to recreate the
resource unit appears to be removing both the compiled unit and resource file.
Is there some sort of flag for this? I'd be fine with just recompiling the
resource file every time the unit is compiled, windres is fast enough...

Please report a bug.

Regards,
Sven

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.f

[Martok]

Post by Sven Barth via fpc-pascal
Please report a bug.

Well this is awkward - I tried to provide a test project for the report, and
couldn't get it to *not* work. The real-world project that has this issue for me
has the resource included from a file in a package, and it seems like this is
somehow significant. Might be more of a Lazarus issue then.

There is still a bug in that the RES is not recompiled if the PPU is present but
the RES is not (causes error 9029), but I'll report that separately, after
figuring out what is going on here...

--
Martok

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo

[Marco van de Voort]

Post by Michael Van Canneyt

Post by Martok
changes/extensions to fcl-res?

I think a lot. There is a request in the bugtracker for a resource compiler since ages.

It comes up regularly. Many people don't even pursue it further, and just
use resources generator by e.g. an old delphi project if needed.

But longterm, we need this for completeness sake.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mai

[Michael Van Canneyt]

Post by Marco van de Voort

Post by Michael Van Canneyt

Post by Martok
changes/extensions to fcl-res?

I think a lot. There is a request in the bugtracker for a resource compiler since ages.

It comes up regularly. Many people don't even pursue it further, and just
use resources generator by e.g. an old delphi project if needed.
But longterm, we need this for completeness sake.

Well, I could use it short term too :)

I imagine lazarus could use it as well to bind icons etc.

Michael.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mai

[Giulio Bernardi]

Hi everybody, I'm just chiming in after quite some years.
Just two notes:

* For lazarus, it shouldn't need to use a real resource compiler for standard
things like icons, manifests etc: see programs res6 and res7 at
https://www.freepascal.org/docs-html/fclres/basic%20usage.html

Post by Martok
The more difficult part is implementing the remaining resource access
classes for fcl-res. Well, not difficult per se, but the
copy-on-write-sharing thing done there adds a lot of complexity for (IMHO)
very little benefit and makes it a bit awkward to work with. There's also
a lot of endian conversions that could probably be factored out.

Actually, fcl-res was designed as a library to be used by a resource compiler,
and I don't think you need to implement new classes at all: once you have
written a parser for .rc files you just have to read the files referred from the
.rc file (icons, raw data etc), create the right kind of resource and add to the
output TResources. IIRC all the standard resource types were already
implemented, so once you write a parser that handles .rc files you should be done.

Giulio

Post by Martok

Post by Marco van de Voort

Post by Michael Van Canneyt

Post by Martok
changes/extensions to fcl-res?

I think a lot. There is a request in the bugtracker for a resource compiler since ages.

It comes up regularly. Many people don't even pursue it further, and just
use resources generator by e.g. an old delphi project if needed.
But longterm, we need this for completeness sake.

Well, I could use it short term too :)
I imagine lazarus could use it as well to bind icons etc.
Michael.
_______________________________________________
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bi

[Martok]

Hi!

Good feedback so far. Given recent... conflicts, I wanted to ask first, just to be sure.

Post by Giulio Bernardi
* For lazarus, it shouldn't need to use a real resource compiler for standard
things like icons, manifests etc: see programs res6 and res7 at
https://www.freepascal.org/docs-html/fclres/basic%20usage.html

That is probably enough for simple resource editor, yes. I believe this is what Lazarus already does for VERSIONINFO resources (?)

Post by Giulio Bernardi
Actually, fcl-res was designed as a library to be used by a resource compiler,
and I don't think you need to implement new classes at all: once you have
written a parser for .rc files you just have to read the files referred from the
.rc file (icons, raw data etc), create the right kind of resource and add to the
output TResources. IIRC all the standard resource types were already
implemented, so once you write a parser that handles .rc files you should be done.

In part, yes. Particularly the really difficult types are already implemented. I would attempt to implement all remaining RT_x
types, including those that are not commonly used in cross-platform targets. Things like DIALOG or MENU have a custom format in
their RawData, but that should be fairly straightforward, basically doing the same as the ACCELERATOR resource and tutorial.

[Martok]

Hi again,

a quick update: I have a somewhat-working version, but many things are still
missing.
We have: a preprocessor, full support for BITMAP, ICON, CURSOR, resource
attributes (LANGUAGE etc.), all RCDATA-like resources, including their
definition from inline literal statements.

What's missing:
- UnicodeString Strings (L"foo")
- various forms of escape sequences for strings
- Concatenated adjacent strings ("ABC" "DEF")
- numeric expressions (used for things like computing flags).
- complex resources: ACCELERATORS DIALOG/EX MENU/EX STRINGTABLE VERSIONINFO

The first two are not that difficult, just awkward (as all encoding-aware
stringhandling is), adjacent strings are more of an issue: turns out this
creates a problem in the language:
FOO BITMAP "900.bmp"
"A NAME" TEXT BEGIN "A String" END
This can't parse right: the filename and resid get concatenated to "900.bmpA
NAME". While entirely correct, that's not very useful. I might leave that out
until someone needs it.
Of the complex resources, STRINGTABLE and VERSIONINFO are probably the more
important ones. Luckily, both already have resource types implemented, so that
shouldn't be too hard either.
It's also leaking memory like a rusty bucket, I have so far completely ignored
what transfers object ownership in fcl-res classes. Heaptrc will hopefully help
here.

I only get to work on this on about one day a week and spend half of that trying
to keep the grammar somewhat readable and with no bad reduce conflicts, but if
anyone wants to play along:
<https://github.com/martok/freepascal/compare/master...fpcres-rc>

[Michael Van Canneyt]

Post by Martok
Hi again,
a quick update: I have a somewhat-working version, but many things are still
missing.
We have: a preprocessor, full support for BITMAP, ICON, CURSOR, resource
attributes (LANGUAGE etc.), all RCDATA-like resources, including their
definition from inline literal statements.
- UnicodeString Strings (L"foo")
- various forms of escape sequences for strings
- Concatenated adjacent strings ("ABC" "DEF")
- numeric expressions (used for things like computing flags).
- complex resources: ACCELERATORS DIALOG/EX MENU/EX STRINGTABLE VERSIONINFO

Seems like you have the main things covered, though.
Nice job and keep up the good work :)

Michael.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freep

[Martok]

More Progress!

I've since finished STRINGTABLE and VERSIONINFO as well as mathematical expressions.

However, there's an issue I hope somebody can help with. Binutils has this test
case:

<https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=binutils/testsuite/binutils-all/windres/version_mlang.rc;hb=HEAD>

Every Resource compiler I have tried compiles this slightly differently, and
Resource Hacker doesn't understand one of them. Could somebody test this with MS
RC and share the res file?


Independently, TVersionResource emits one Translation block per translation
instead of one containing all translations. I take it that isn't formally wrong,
but it's also not optimal? Was this intentional?

[Marco van de Voort]

Post by Martok
However, there's an issue I hope somebody can help with. Binutils has this test
<https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=binutils/testsuite/binutils-all/windres/version_mlang.rc;hb=HEAD>
Every Resource compiler I have tried compiles this slightly differently, and
Resource Hacker doesn't understand one of them. Could somebody test this with MS
RC and share the res file?

I happened to have an old win8 sdk around (vs community edition didn't seem
to have "RC"). Anyway:

http://www.stack.nl/~marcov/funkyres.res


_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-

[Martok]

Post by Marco van de Voort
I happened to have an old win8 sdk around (vs community edition didn't seem
http://www.stack.nl/~marcov/funkyres.res

Thank you!

Funky indeed, I'll mark that down as a Reshacker bug then.

Off to String stuff then.