Dear FPC-all!

I have a big projects with lots of DLLs. All of them are cross-platform and link the resources with $R directive.

For version info I use .rc scripts to manage it under VCS and to prevent .RES flicker under different compilers (FPC and Delphi)

Version info is a nice example.

{$R script.rc srcipt.res}

This kind of resource management implies usage of windres (or any other RC script compiler)

With the crosscompilation things became funnier:

I can under Linux get win32 exe with mingw-windres

I can under Linux get Mach-O 32 exe with odcc-windres

I can NOT under MacOS get Mach-O 32/64 exe with resources.

So the question - why current FPC can link .res under any platform (with the help of fpcres) but cannot build such file under any platform without foreign tools?

Is not the time came for own resource compiler for limited type of resources (BITMAP, CURSOR, MANIFEST, VERSIONINFO)?

with best regards,

Anton

"Anton Kavalenka" wrote

So the question - why current FPC can link .res under any platform (with

the help of fpcres) but cannot build such file under any platform without foreign tools?

Because there's no cross platform Pascal only tool for this.

Is not the time came for own resource compiler for limited type of

resources (BITMAP, CURSOR, MANIFEST, VERSIONINFO)?

Patches welcome.

Regards,
Sven

Can't you just convert the the .rc file to .res (with windres on any platform) and then let FPC convert the .res file to the appropriate object format?

Is not the time came for own resource compiler for limited type of resources (BITMAP, CURSOR, MANIFEST, VERSIONINFO)?

I would argue we already have plenty of things to maintain that are tangential to the compiler itself. Additionally, while the above might be enough for use case, it doesn't work to do this for a large and generic project. We either do something well, or

Anton Kavalenka wrote

Is not the time came for own resource compiler for limited type of resources (BITMAP, CURSOR, MANIFEST, VERSIONINFO)?

It should not be a problem for a very limited syntax.

But if you look at what delphi resource compiler can do then you find a very hard to implement feature - "include directive" which allows to use macroses and constants from .pas, .h and .cpp files.

Paul Ishenin wrote

21.11.2016 21:13, Anton Kavalenka wrote: > Is not the time came for own resource compiler for limited type of > resources (BITMAP, CURSOR, MANIFEST, VERSIONINFO)? It should not be a problem for a very limited syntax.

I have a Version.r file that does things like

#define __version_hi_num__ 2
#define __version_mid_num__ 0
#define __version_lo_num__ 5

I can include the defines in an .rc file

#include "Version.r"

The .rc file can be compiled to a .res with windres on various platforms, either cross or native. Note that when running windres, you can specify the preprocessor to use, e.g. gcc. The .res can then be linked into the application using fpc.

On Mac OS X, I can

#include "Version.r"

in a MacOS .r file. The .r can compiled with Rez to a flat resource file or into a resource fork. Also, I can use the version defines in a Mac OS X plist using sed and the output of a small C program

#include <stdio.h>
int main( void )
{
   printf( "s|__CFBundleExecutable__|"__product__"|g\n");
   printf( "s|__CFBundleGetInfoString__|"__product__" "__version_description__",
"__written_by__"|g\n");
   printf( "s|__CFBundleIdentifier__|"__product_identifier__"|g\n");
   printf( "s|__CFBundleName__|"__product__"|g\n");
   return 0;
}

So, for me it works for all the platforms I need. Of course, the .rc would use the version defines differently than the MacOS version info or the plist, but that needs to be setup only once.

Yes, this is very much like C, I don't like that either, but it does work.

Regards,

Adriaan van Os