Hi,

To compile programs from the console (no IDE's) I normally create a extrafpc.cfg file with the compiler parameters I need per line.

Usage:
fpc @extrafpc.cfg myprogram.pas

I have use the $fpctarget macro for unit output for years, and this works under Windows, Linux and FreeBSD.

eg:
-FU../lib/$fpctarget/

The output is normally something like "../lib/i386-linux/" or "../lib/x86_64-freebsd/".

But under OS/2 that macro translates only to to the text "os2", thus the Unit Output Path ends up being: "..\lib\os2\" when I actually expected "..\lib\i386-os2\"

Why isn't the "i386-" part added? Is this expected behaviour?

I'm using FPC 2.6.4 and eComStation 2.

Regards,
- Graeme -

On Sun, November 8, 2015 12:03, Graeme Geldenhuys wrote:

Hi Graeme,

.
.

.
.

Yes, it works as designed. The same happens with target GO32v2. The reason is that these targets may be used with 8.3-limited file system (the original FAT) and thus the target OS is used there without the CPU prefix to reduce the barriers (it doesn't have any unwanted side-effectsn because these targets are not supported on other CPUs anyway). Most users wouldn't even notice it (especially considering the fact that cross-compilation to the OS/2 target from other hosts isn't very easy at the moment).

Tomas

Tomas Hajny wrote

Yes, it works as designed. The same happens with target GO32v2. The reason is that these targets may be used with 8.3-limited file system (the original FAT)

Wow, does anybody actually install OS/2 on a FAT filesystem? In all my years of using OS/2, I've only ever come across OS/2 on HPFS, and in eComStation it defaults to JFS. But I get that it is a faint possibility. Thanks for clearing that up.

these targets are not supported on other CPUs anyway). Most users wouldn't even notice it (especially considering the fact that cross-compilation to

I wasn't doing cross-compilation. I have a build script for fpGUI that creates the unit output path (seeing that FPC doesn't create paths at compile time), then I compile the framework using that path.

eg: here is my Linux version of such a build script.

========================
fpcbin=fpc
fpctarget=`$fpcbin -iTP`-`$fpcbin -iTO`
#echo $fpctarget
libpath='../lib/'$fpctarget

# Must we create the output directory?
if [ ! -d $libpath ]; then
echo 'creating directory: '$libpath
mkdir $libpath
echo ' '
fi

# Default build
$fpcbin -dX11 @extrafpc.cfg corelib/x11/fpgui_toolkit.pas ========================

But no worries, it isn't hard modifying my build.cmd and extrafpc.cfg to adjust for this.

@Tomas:
As you are the only regular FPC OS/2 user here that I know of, and if you haven't deduced it yet... fpGUI Toolkit will soon add OS/2 as one of the officially supported platforms. :)

Regards,
- Graeme -

Graeme Geldenhuys wrote

On 2015-11-08 13:26, Tomas Hajny wrote:

.
.

.
.

Alright, but the difference between build.sh and build.cmd is much bigger than the $fpctarget anyway (I understand that the difference between build.cmd for MS Windows and build.cmd doesn't need to be so big if you're careful).

@Tomas: As you are the only regular FPC OS/2 user here that I know of, and if you haven't deduced it yet... fpGUI Toolkit will soon add OS/2 as one of the officially supported platforms. :)

Glad to hear that. :-) I don't do GUI programming, but it's good to have a simple option easily available in case the need arises. I'll be happy to help you with resolution of any possible incompatibilities in the OS/2 RTL you might discover while implementing the OS/2 support.

BTW, there are few more OS/2 users subscribed to this list, although certainly not too many.

Tomas

Tomas Hajny wrote

Alright, but the difference between build.sh and build.cmd is much bigger than the $fpctarget anyway

Oh yes I understand that. I didn't mean I share a build script between platforms. Each platform has its own build script... I just showed the Linux one as an example.

Glad to hear that. :-) I don't do GUI programming, but it's good to have a simple option easily available in case the need arises.

And WDSybil is definitely not up to the task - very outdated. I use the editor portion only at the moment, but hope to have Maximus IDE running under OS/2 soon.

I'll be happy to help you with resolution of any possible incompatibilities in the OS/2 RTL you might discover while implementing the OS/2 support.

Many thanks.

Regards,
- Graeme -