Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2014-12

$FPCTARGET macro and friends

3 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

waldo kitty

i'm trying to figure out the macros to have FP search for and output files in

i386-win32
i386-os2
i386-linux

and similar... i had thought that $FPCTARGETCPU-$FPCTARGETOS would work but apparently not... so, without hardcoding them, how can i have FP use the same directories that Lazarus uses?

can i use the ones like %FPCTARGETOS% and %FPCTARGETCPU% in the options->directories path definitions?

there are times that i must use FP because there's no GUI on the machine...

NOTE: No off-list assistance is given without prior approval. Please *keep mailing list traffic on the list* unless private contact is specifically requested and granted.

Reply by email

Tomas Hajny
to waldo kitty
waldo kitty wrote 9 lines
i'm trying to figure out the macros to have FP search for and output files in i386-win32 i386-os2 i386-linux and similar... i had thought that $FPCTARGETCPU-$FPCTARGETOS would work but apparently not... so, without hardcoding them, how can i have FP use the same directories that Lazarus uses?

Under which (host) operating system does that FP run? The OS/2 compiler and IDE (and Makefiles, etc.) are configured to use shorter version of the $FPCTARGET macro (only the target OS without the CPU platform), because on one hand, OS/2 isn't supported on multiple CPU types anyway, on the other hand, this allows compilation also on OS/2 installations using FAT drives (i.e. without LFN) and also e.g. assembling and linking of programs compiled for the GO32v2 target using the GO32v2 as.exe and ld.exe under OS/2 (which wouldn't be possible otherwise, because they wouldn't see directories with long names under OS/2).

I'd be interested to understand the particular scenario you want to cover. As an example, if you e.g. access some shared network drive with your sources from multiple operating systems and want to use one installation of e.g. the OS/2 files used for all of Linux, Win32 and OS/2, you could set up symlinks (Linux) / junctions (MS Windows) on the file server so that 'i386-os2' used on one platform points to the same physical place as 'os2' used by the OS/2 installation. Note that this scenario is not officially supported by FPC (although workable with the minimum effort outlined above).

Tomas

Reply by email

waldo kitty
to Tomas Hajny
Tomas Hajny wrote 14 lines
On 3 Dec 14, at 16:38, waldo kitty wrote: > i'm trying to figure out the macros to have FP search for and output files in > > i386-win32 > i386-os2 > i386-linux > > and similar... i had thought that $FPCTARGETCPU-$FPCTARGETOS would work but > apparently not... so, without hardcoding them, how can i have FP use the same > directories that Lazarus uses? Under which (host) operating system does that FP run?

i was trying to do this on the vista installation... the goal was mainly for conformity and uniformity...

The OS/2 compiler and IDE (and Makefiles, etc.) are configured to use shorter version of the $FPCTARGET macro (only the target OS without the CPU platform),

yeah, i figured that out when i went to changing the target and saw how $FPCTARGET was being filled in in the exe output path...

because on one hand, OS/2 isn't supported on multiple CPU types anyway,

not even powerpc? ;)

on the other hand, this allows compilation also on OS/2 installations using FAT drives (i.e. without LFN)

yeah, i never had any luck with trying to use FPC on fat drives... not the OS/2 version or the DOS version so i abandoned that and went back to full HPFS and only the native OS/2 flavor of FPC... *but* i do have some things that i need to be able to do in a DOS set up but i've been falling back to my TP/BP 6/7 stuff for that... making the switches back and forth is pretty tough to do at times...

Show quoted text 5 lines
and also e.g. assembling and linking of programs compiled for the GO32v2 target using the GO32v2 as.exe and ld.exe under OS/2 (which wouldn't be possible otherwise, because they wouldn't see directories with long names under OS/2).

i've never used GO32 stuff... i really don't need it for my DOS stuff, either... that's another reason why i drop back to my old BP/TP installs... GO32 just adds too much that i don't need for those projects (eg: DOS BBS Doors)...

I'd be interested to understand the particular scenario you want to cover.

as above, just uniformity to make scripting packaging easier... or so i thought... plus attempting to cross-compile... i've never done that and wanted to see if it could be done easily... so i found the win32->OS2 binutils and added them to my vista installation and gave it a go... that's when i realized that i need to adjust the paths to use some sort of TARGETOS and TARGETCPU stuff so i started playing around and trying things since there's nothing available (documentation) that's worth a darn telling how to do this... at least nothing i found that a beginner could easily understand and that was oriented to winwhatever as the base platform (for now) with basically the same for doing similar for other platforms...

Show quoted text 8 lines
As an example, if you e.g. access some shared network drive with your sources from multiple operating systems and want to use one installation of e.g. the OS/2 files used for all of Linux, Win32 and OS/2, you could set up symlinks (Linux) / junctions (MS Windows) on the file server so that 'i386-os2' used on one platform points to the same physical place as 'os2' used by the OS/2 installation. Note that this scenario is not officially supported by FPC (although workable with the minimum effort outlined above).

yeah, i don't have anything here that i can do that with... especially nothing SAMBA or NETBEUI styled... the OS/2 box is on another network from the other machines and those protocols are not routable... i used to do such a long time ago but i've separated things so that the servers are separate from the workstations for obvious security reasons ;)

NOTE: No off-list assistance is given without prior approval. Please *keep mailing list traffic on the list* unless private contact is specifically requested and granted.

Reply by email