SystemC library directory not detected correctly

[philipp.hartmann@…]

If not explicitly set in the user's config, the SystemC library dir is not detected correctly. This is due to _platform() in source:trunk/soclib/utils/lib/python/soclib_cc/config/built-in.conf#L23.

For the officially supported achitectures, the following fail currently:

• 64-bit Linux
• Sun Solaris
• HPUX

For "newer" versions of SystemC, the follwing are most probably not working as well:

• Mac OSX (i386)
• Windows (with MinGW)
• FreeBSD (and FreeBSD 64-bit)

In our local scripts, we currently use the following mapping (with SYSTEM_ARCH defined by Autoconf):

 case "${SYSTEM_ARCH}" in
    sparc-sun-solaris*)               echo 'gccsparcOS5'  ;;
    x86_64*linux*)                    echo 'linux64'      ;;
    *linux*)                          echo 'linux'        ;;
    i?86-apple-macosx*)               echo 'macosx386'    ;;
    powerpc-apple-macosx*)            echo 'macosx'       ;;
    amd64*freebsd* | x86_64*freebsd*) echo 'freebsd64'    ;;
    *freebsd*)                        echo 'freebsd'      ;;
    *cygwin*)                         echo 'cygwin'       ;;
    *mingw*)                          echo 'mingw'        ;;
    *hpux11*)                         echo 'gcchpux11'    ;;
  esac

[Nicolas Pouillon]

This table is interesting. Unfortunately, SYSTEM_ARCH is the kind of output spilled from config.guess (a beautiful but bloated shell script from GNU). I'm not quite sure calling config.guess each time soclib-cc is loaded is a good idea.

So I don't know any equivalent way of producing the SYSTEM_ARCH value expected here.

If you know an equivalent of this table, but indexed by an easy-to-obtain data (like output from python's os.uname() and sys.platform), I'll happily integrate it.

Other option I considered some day

make the default path "magic" in the way it looks into the filesystem and finds all the lib-* in ${SYSTEMC}…

Comments welcome

[Philipp A. Hartmann <philipp.hartmann@…>]

I agree with your concerns of calling config.guess each time. To be honest, we obtain the architecture currently via the (GCC) compiler:

SYSTEM_ARCH:=`${CXX} -dumpmachine`

We actually only use it in case the environment variable SYSTEMC_LIB is not already set to the proper library directory.

"Porting" the table to a Python version based on platform.machine() and platform.system() should be possible, though. At least for the most popular platforms.

[Nicolas Pouillon]

First attempt

[Nicolas Pouillon]

Integration proposal in built-in.conf.diff​, does this improve anything ?

[philipp.hartmann@…]

Looks good (although not tested yet, a colleague of mine will try it later). You might need to separate the FreeBSD64 case to two lines, though:

# might not work
  ("amd64*freebsd* | x86_64*freebsd*",  'freebsd64'  ),
# this should do it
  ("amd64*freebsd*",   'freebsd64'  ),
  ("x86_64*freebsd*",  'freebsd64'  ),

[philipp.hartmann@…]

Another comment: In _guess_directory you fall back to the first lib- directory. Maybe it is safer to do this only in case of a unique match. For instance, we have shared installations, that contain several lib- directories for various architectures. Therefore, the first match is not always correct.

Something like:

from fnmatch import fnmatch

systemc = os.getenv('SYSTEMC')

if systemc:
    dirs = fnmatch.filter( os.listdir(systemc), 'lib-*' )
    if len(dirs) == 1:
        return dirs[0][4:]

return None

[Nicolas Pouillon]

Sure, taking both remarks.

[Nicolas Pouillon]

Second attempt

[philipp.hartmann@…]

Typo :-)

  if len(candidates) == 1: 
-     return d[0][4:]
+     return candidates[0][4:]

[Nicolas Pouillon]

You were too fast, I fixed it meanwhile :)

[Nicolas Pouillon]

Attempt #2 integrated in [1849]