QMake and alternate files.

[prime]

Hi all,

To try and seperate my hardware from the original QLSD hardware I need to seperate some of the routines into alternates depending on which version is being compiled, but to keep the bulk of the code common.
For the original QLSD code, I did this with a bunch of GENIF statements, I'll still need one of these in the keys file as locations and offsets of the IO in my hardware are different.
However for the other low level code I could easily do this via alternate files. So for example sendcmd.asm and sendcmd_phs.asm.

The problem I see comes with the fact that I think qmake is trying to work out which routines are defined in which files, and link them accordingly, will having mutiple files exporting the same labels with XDEF be a problem?
Is there a way of overcoming this?

For now I'll continue using GENIF, but the mutiple files might be better.

Cheers.

Phill.

[tofro]

The problem I see comes with the fact that I think qmake is trying to work out which routines are defined in which files, and link them accordingly, will having mutiple files exporting the same labels with XDEF be a problem?
Is there a way of overcoming this?

QMake is not that clever (and doesn't need to be). It's the linker (called by QMake) that resolves the various xdef and xref'ed symbols.

If you give QMake a list of _rel files that LINK should link together, it will hand those over to LINK and LINK will complain if an XDEFed symbol is defined in there more than once.

If you give QMake a library, however (that is, concatenated _rel files) with the LIBRARY keyword, LINK will only search that library (or multiple libraries) until it can resolve all the symbols that it needs to (it doesn't do an exhaustive search). LINK will happily accept multiple libraries that export the same symbols, because it won't look into libraries for symbols it has already found elsewhere.

This is called shadowing, and I don't understand your problem good enough to judge whether this could be an advisable way to go (because it can be a way to shoot yourself into the foot a lot).

[mk79]

If you have different files you need different _link files. Alternatively one could use the substitution feature to switch between different configurations in the same link file, but so far that was usually used to switch between different languages.

Currently I cannot say which way is better, it might well be that local GENIFs are preferable or maybe different macros. My main goal is not to have a) any additional burden maintaining the code base and b) any code increase because it's already a fight for every byte to fit into the ROM.

[prime]

Currently I cannot say which way is better, it might well be that local GENIFs are preferable or maybe different macros. My main goal is not to have a) any additional burden maintaining the code base and b) any code increase because it's already a fight for every byte to fit into the ROM.

I have looked at both, a GENIF to switch between the port layouts, and a macro for controlling the instruction used to make the interface read the next byte from the SD.

Code increase for my hardware is less of a problem as I have a proper write port so don't need the 256 bytes at the end that are used to make the original hard ware write the bytes by reading them.
But I have to make sure my changes don't increase the size of the original code.

Cheers.

Phill.