@SamuraiCrow
If you are going that route, where the target-specific code is stored (or loaded) by different main executable code, then you might find it useful to declare prototype procedures, so that your shared code can refer to the procedures in the main executable.

More on prototypes here:
http://cshandley.co.uk/portable/PortablE.html#9_4

But the basic gist is you have your dummy 'base' procedure:

Quote:

And then in the main executable code (or a module used by it, which also depends on the module containing the prototype procedure) you have the real code:

Quote:


P.S. You can thank Deniil for prompting me to add this feature. Which I was easily able to add, since I'd already implemented REPLACEMENT of existing procedures. And I subsequently found that PROTOTYPEs were *very* handy for implementing some modules.

What I decided on was to put all the main executable code in a module that would be imported from two different main programs.

I should add that if you have a module which shares most of it's code with several targets, then it can make sense to use #ifdef enable/disable code for those different targets.

But if you start using #ifdef over too much code (especially whole procedures or objects), then you might wish to move the different parts to different modules in the way I outlined in my previous post.

It's correct, you cannot have preprocessor commands before MODULE (and OPT). This is due to some differences between how PortablE & AmigaE operate, although thinking about it now it seems to me it *might* be possible to allow it (with some difficulty).

Anyhow, the current way to achieve what you want is to use the special PEModules:target folder. Inside there you will see folders for different targets like "CPP_AmigaOS4", "CPP_AROS", "AmigaE_AmigaOS3", etc. If your module is only used by one of these targets, then you can put that module directly there, for example:

PEmodules:target/CPP_AmigaOS3/SamuraiCrow/graphics.e

You would then access it using:

MODULE 'target/SamuraiCrow/graphics'


But for modules which you want to share with several targets, you will need to create some "alias modules". For example:

PEmodules:target/CPP_AmigaOS4/SamuraiCrow/graphics.e
PEmodules:target/CPP_AROS/SamuraiCrow/graphics.e
PEmodules:target/CPP_MorphOS/SamuraiCrow/graphics.e

Each of which would contain something like this:

Quote:

And then you would put your actual shared code here:

PEmodules:SamuraiCrow/graphics_OS.e


I hope that makes sense? Here is an existing example of a module for different targets (the first module is shared by several targets):

PEmodules:targetShared/Amiga/CSH/pAmigaRTG_CGX.e
PEmodules:target/CPP_AmigaOS4/CSH/pAmigaRTG.e
PEmodules:target/CPP_AmigaOS3/CSH/pAmigaRTG.e
PEmodules:target/AmigaE_AmigaOS3/CSH/pAmigaRTG.e

The first one is pointed at by these "alias modules":

PEmodules:target/CPP_AROS/CSH/pAmigaRTG.e
PEmodules:target/CPP_MorphOS/CSH/pAmigaRTG.e

Which means that all of those modules are referred to by this single statement:

MODULE 'target/CSH/pAmigaRTG'

You might even find this module useful yourself! But beware that any modules inside the "CSH" folder (which is my personal folder) are undocumented... and subject to change without notice, potentially in ways which break backwards compatibility at the source level! Only modules inside PEmodules:std are intended to stay backwards compatible (and are documented of course).

Note that you COULD use the PEmodules:targetShared/ folder like I have, but I would tend to advise against it since the folder structure inside there is subject to change (and it might be confusing to see PortablE's files/folders mixed with yours). You'd probably be better using something like PEmodules:SamuraiCrow/shared/ . Certainly you must NEVER use an existing "PE" folder (such as PEmodules:PE/) as I consider them 'private' folders for use only by PortablE.

Hello. I'm in the process of writing a tech demo of a game interface. I want to be able to do MODULE 'aga' for the AGA version and MODULE 'gfxcard' for the other versions.

The display logic will be totally different from the gfxcard version (which will use the PortablE standard classes) and I'll be banging hardware or using Graphics.library at least for the AGA version.

I don't want to include both modules in the same executable because it will waste memory if that happens so using OOP inheritance is out of the question. I'm trying to use an #ifndef for the exclusion case of AGA but PortablE insists that it is illegal to have an #ifndef command before the last MODULE or OPT keyword is there.

How would you recommend doing this? I guess this is kind of like generics but without a base setup. There will be only a few public procedures in the interface and I'd like to keep it that way.