#81 Have two versions of MFront in the same environment

[Mickael ABBAS]

Hello,

I open this ticket to allow two versions of MFront in the same environment

[mcourtois]

Pour ma part, j'ai proposé la solution suivante à Mickael:

• rajouter le numéro de version aux librairies et aux exécutables, ainsi qu'aux modules python
• faire des liens pour être compatible avec ce qui est fait actuellement.

C'est ce à quoi je pensais.
Il faut aussi le faire pour le répertoire des includes.
On n'a pas besoin d'installer ces deux versions sous le même préfixe donc pas la peine par exemple d'avoir deux versions de la doc dans share/doc/mfront ou des tests...

Si on modifie l'environnement (LD_LIBRARY_PATH, PYTHONPATH), il faudrait par exemple :
./bin/mfront3.0 (ou tfel-config3.0 pour ceux qu'on appelle)
./lib/libAsterInterface3.0.so

Pour les includes, comme ce n'est utilisé qu'à la construction de code_aster, le plus simple est sans doute :
./include/MFront3.0/MFront/ et ./include/MFront3.0/TFEL/

Pour les packages Python, je pense qu'il faut forcément modifier le PYTHONPATH pour passer d'une version à l'autre...

[Helfer Thomas]

In cmake, the TFEL_APPEND_VERSION option will append the version number to the names of:

• The executables.
• The libraries.
• The python modules. Note that, to comply with python restriction
  on module' names, the characters . and - are replace by _ and
  that only the first level modules are affected.
• The directories in the share folder.

The headers are installed in a subforder named TFEL-${TVEL_VERSION}.

For example, if the TFEL version is 3.0.2-dev, using TFEL_APPEND_VERSION opion will generate:

• The mfront-3.0.2-dev executable.
• The libTFELMaterial-3.0.2-dev.so library.
• The mtest_3_0_2_dev python module.
• The tfel_3_0_2_dev.material python module. In this case, the
  second level (material) is not affected.

This allows multiple executables to be installed in the same directory.

The tfel-config tool

The tfel-config tool has been modified to take this option appropriately. For example:

$ tfel-config-3.0.2-dev --includes
-I/tmp/install/include/TFEL-3.0.2-dev
$ tfel-config-3.0.2-dev --libs --material
-L/tmp/install/lib -lTFELMaterial-3.0.2-dev -lTFELMath-3.0.2-dev -lTFELUtilities-3.0.2-dev -lTFELException-3.0.2-dev

Modification to mfront

mfront has been modified to call the appropriate tfel-config executable.

For more details, see: https://sourceforge.net/p/tfel/tickets/81/

An helper function for importing TFEL modules

Users of the python modules could use the following functions:

import os, importlib

def python_module_version(v):
    """Return the python module extension from the TFEL version"""
    return v.replace('.','_').replace('-','_')

def import_tfel_module(n,*v):
    """Try to import a tfel module, taking into account the TFEL_VERSION environment variable."""
    if not n:
        ImportError('Empty module name')
    m   = n.split('.')
    if not v:
        env = os.environ;
        if('TFEL_VERSION' in env):
            v = env.get('TFEL_VERSION')
            m[0] = m[0]+'_'+python_module_version(v)
    elif len(v)==1:
        m[0] = m[0]+'_'+python_module_version(v[0])
    else:
        ImportError('Invalid number of arguments')
    return importlib.import_module('.'.join(m))

[Helfer Thomas]

Fixed in revision 1780 in trunk.
Fixed in revision 1781 in rliv-3.0.

[Helfer Thomas]

Note that one can install a version with and without TFEL_APPEND_VERSION. I suggest that without the version without TFEL_APPEND_VERSION is the official one (i.e. the one officially supported by Code_Aster and that the others are meant to test newer versions.

The other valid strategy is to use the TFEL_APPEND_VERSION for the official version, but this leads to more compilcated developments in Code_Aster, including changing the name of the mfront executable in every tests.

Regards,
Thomas