Thursday, August 21, 2008

Synesis Software Object Library Naming Conventions explained ... I think

I'm writing up some docs as part of the seemingly never-ending process of getting Pantheios ready for its 1.0 final release. Part of this is documenting the object library naming conventions.

For a given Synesis Software project (Pantheios, FastFormat, UNIXEm, shwild, etc.), the object libraries are named according to the following convention:


Some examples might help.

For the Pantheios core library for VC++ 9 in DLL configuration and debug mode the library name would be:


For the Pantheios core library for GCC 4.2 in multithreaded configuration on UNIX the library name would be:

So far so good. Let's jazz it up a little. Consider the NoX - No eXception - builds, which are usually only provided for VC++ 6. Let's say we now want a NoX build of the single-threaded VC debug object library:


And the multithreaded (non-DLL) version:

Where this starts to fall down is in two ways: when emulating UNIX builds on Windows, and when defining x64 builds of UNIX. For a first example, let's look at the UNIX-emulation, non-NoX variant of the last VC 6 one:

Even this has a certain consistency about it. But where it currently really starts to fall down is with the 64-bit Windows versions of things. Consider an x64 version of the VC 9 configuration. It is currently:

Ideally this should be changed to:

But then if we're emulating 64-bit UNIX on x64, how would we represent this? Would it be:



I'm keen to get some external opinions on this, as the inconsistency can't stand, but making such changes now will be significant.

The other aspect of this issue is that all the changes to all Synesis libraries will have to be made pretty much at once. This is sticky stuff ...


Cláudio said...

Hi Mathew,

The way I solved this "issue" was to separate the x86 and x64 LIBs by using a different directory.

Since I mainly use just one platform I don't have the right felling for the ones stated...

Though my personal opinion would go to:

This is because for windows will probably end up being:

And this comes close to the WIN64 #define.

Cláudio Albuquerque

Matt Wilson said...

> The way I solved this "issue" was to separate the x86
> and x64 LIBs by using a different directory.

That's kind of what I've decided on. I'll post another item on it, as soon as I've got time.