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:

  [lib]<library-name>.<major-version>.<module-name>
  .<compiler-name>[.<os-arch-tag>]
  [.<threading-tag>][.<nox-tag>][.<debug-tag>].{a|lib}

Some examples might help.

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

  pantheios.1.core.vc9.dll.debug.lib

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

  libpantheios.1.core.gcc42.mt.a

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:

  pantheios.1.core.vc6.nox.debug.lib

And the multithreaded (non-DLL) version:

  pantheios.1.core.vc6.mt.nox.debug.lib

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:

  pantheios.1.core.vc6.unix.mt.debug.lib

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:

  pantheios.1.core.vc9_x64.mt.debug.lib

Ideally this should be changed to:

  pantheios.1.core.vc9.x64.mt.debug.lib

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

  pantheios.1.core.vc9.unix.x64.mt.debug.lib

or:

  pantheios.1.core.vc9.x64.unix.mt.debug.lib

or:

  pantheios.1.core.vc9.unix_x64.mt.debug.lib

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 ...