Finish Linux support in loc tool

[bolle732]

On Linux, the loc utility currently prints an error message telling no *.rsc files are found. Furthermore, it appears it does not put the chunk names from the *.rsc files into the generated .vm file. The VM file can be used in ResEdit, but without the hints from the @localize, it is difficult and error prone.

As far as I've seen in the source code, there is a compat.c include for _WIN32 ifdefs. The same would be needed for _LINUX.

[bolle732]

More research showed that the argument handling and the code paths are different between MSDOS / WIN32 and LINUX platforms. The function LocErr() isn't compatible with the Linux code path.

Specifying the resource files as additional arguments builds a usable VM file:

$ loc -o <APP>.geo rsc.rsc <A>.rsc <B>.rsc ...

[bluewaysw]

Good find and fix! But why the needed rsc were not found in the first hand?

[bolle732]

I followed the advice of the other SDK programmers working under Windows. There you don't have to specify the .rsc files whereas under Linux you must specify them.

Windows: loc -o <APP>.geo

Linux: loc -o <APP>.geo rsc.rsc <A>.rsc <B>.rsc ...

This is due to the different handling in the different code paths...

[bolle732]

I think, they where found, but the error message was misleading. Maybe I've also run into the bug, that ResEdit doesn't show the chunk names after updating the VM file. But unfortunately, I don't remember exactly. Need more experience with the tools...

[rabe-soft]

I can't imagine that you can't do this under Linux so that the rsc files are found automatically. Ok, I have no idea about Linux.

[rabe-soft]

Better, try to set the foundFlags correctly.

[bluewaysw]

From my perspective looking at the pull-request, this is not changing actual behaviour of the tools. All CI build are on Linux and produce correct .vm files. So I was wondering what happed for you seeing broken vm files.

[bluewaysw]

But yes, you are right, the auto-rsc-file scanning is an WIN32/MSDOS-only feature in the implementation.

[bolle732]

From my perspective looking at the pull-request, this is not changing actual behaviour of the tools. All CI build are on Linux and produce correct .vm files. So I was wondering what happed for you seeing broken vm files.

That's correct. The change only disables the misplaced messages under Linux. That about broken VM files could be due to my messy tests trying to figure out how the whole localization should work.

So, in my eyes, you could apply the small fix for convenience of the programmers under Linux like me. The real fix for the long run would be to streamline the arguments and behavior for all platforms.

[rabe-soft]

IMHO pmake full should produce correct vm files an all platforms.

[bolle732]

Ok, I've tested the whole build again from a clean state of my application. Then I did:

$ mkmf
$ pmake depend
$ pmake full

The last output is:

--- geoladder.vm ---
loc  `perl /home/bolle/pcgeos/Tools/scripts/perl/product_flags loc ` -o geoladder.vm `ls *.rsc `

So, under Linux, the resource files are listed ias arguments of loc command.

The VM file is also created:

$ ls -la *.vm

-rw-rw-r-- 1 user user 7360 Jul 1 15:00 geoladder.vm

Using the produced .geo and .vm files in ResEdit works perfectly.

Therefore, pmake full works under Linux too.

The conclusion here would be, that I missed the knowledge about the differences between WIN32 / MSDOS and LINUX platforms and followed a misleading message and an inappropriate advice.

Maybe we finish this issue with the fix and open another issue for streamlining the tools for all platforms? An idea could be to use getopt for all handling of command line arguments and options.

[rabe-soft]

Great! Can you check under Linux whether there is an rsc.rsc? Then you can run this test instead of LocErr and display a warning that no .rsc files were found and the NC version must be built. This is not as detailed as under Windows, but it does the job.

[bolle732]

Yes, there is a rsc.rsc file under Linux too.

So, you mentioned that if no chunks are in the source files, no resource file is generated. If this is currently true, then how can loc differentiate the cases:

• user is creating EC version
• there are no chunks in the sources

To really address this problem we need to:

• detect EC build
• change the build to generate empty resource files

Then we can implement a real fix for that. Unfortunately, I can't say what happens later in the build process if empty resource files exists.

Sorry for being so pigheaded...

[bolle732]

We'll continue with this at issue #604