Platform types to support

Hi all,

Currently Paladin tries to detect the user’s Platform on loading a project, and then resets the Project platform to the detected platform.

This is causing an issue whereby if multiple developers work on the same project file, one on 32bit the other on 64 bit, their git commits will be awash with the project file as this string changes.

The detection can be found here: https://github.com/adamfowleruk/Paladin/blob/master/Paladin/Project.cpp#L1636

I have a couple of questions:-

  1. Does it make more sense to have a project setting for ‘target platform’ rather than detect the current user’s platform?
  2. Is there really a difference between platform strings of “Haiku” vs “HaikuGCC4” as detected by this function?
  3. In other parts of the code, Zeta is mentioned. I know there’s no need to support this any more. Are there any other platform aberations that should just be removed?
  4. Does anyone want/need a ‘32 bit project only’ setting for Paladin (I think yes, but just want to check…)

Thanks in advance.

I guess you can go the Visual Studio way and be able to select per project as output. Or having several configs for the project.

Tldr: option 1 looks good for me.

First off, I’m not a hardcore developer and actually don’t know much about the platform differences from a dev point of view. It’s mainly slightly different include paths etc.?

How about making the project file plattform agnostic? Always save for both plattforms and use the ones needed for the detected platform. Like:

SYSTEMINCLUDE_32=/yadda/yadda
SYSTEMINCLUDE_64=/yadda/yadda
LIBRARY_32=/yadda/yadda
LIBRARY_64=/yadda/yadda

Extend for ppc, arm, misp, m68k when needed.

Yep.

If you dare to open a VS project file, you see that their xml goes as:

<SelectedConfig>win32-release</SelectedConfig>
<ConfigGroup>
    <Config tag="win32" mode="release">lottaYaddaYadda</Config>
</ConfigGroup>
<ConfigGroup>
    <Config tag="win64" mode="release">lottaYaddaYadda</Config>
</ConfigGroup>
...

So you can add platforms “indefinitely”, without increasing the param names in ini format.

I have much expierience with IDEs, so i would detect it automatically and add a settings part to change it manualy

2 Likes

If there is a way to detect wich system is running, you can make it variable.

Make all much flexible you can. Many things are only matching by creating the binarie right? Let the user select.

Alternatively, one could drop the Paladin project format altogether and use the Makefile Engine instead, which handles this already.

5 Likes

I like that idea that the IDE understands how the makefile works and imports the files accordingly to how the make file looks like (and categorize them). That would be a killer feature (IMO).

2 Likes

Sounds good, but that one have to know of data input to give it up to the makefile engine? Is it documented?

Funnily enough, I have thought about that. Not realy dug in to makefile-engine enough yet though… Definitely on the RADAR.

I’m trying not to force a particular build regime in case it messes with port developers, or developers in other languages that Paladin may (in future) support…

Well, then using a plug-in based model to support different build engines makes sense then.

1 Like