path = path + [start]
if start in end:
return path
- if not graph.has_key(start):
+ if start not in graph:
return None
for node in graph[start]:
if node not in path:
def run(args, runner, logger):
'''method that is called when salomeTools is called with compile parameter.
'''
- # DBG.write("compile runner.cfg", runner.cfg, True)
# Parse the options
(options, args) = parser.parse_args(args)
all_products_infos = src.product.get_products_infos(runner.cfg.APPLICATION.products,
runner.cfg)
all_products_graph=get_dependencies_graph(all_products_infos)
- logger.write("Dependency graph of all application products : %s\n" % all_products_graph, 6)
+ #logger.write("Dependency graph of all application products : %s\n" % all_products_graph, 6)
+ DBG.write("Dependency graph of all application products : ", all_products_graph)
# Get the list of products we have to compile
products_infos = src.product.get_products_list(options, runner.cfg, logger)
sat compile <application> --show
+* Print the recursive list of dependencies of one (ore several) products: ::
+
+ sat -v5 compile SALOME-master -p GEOM --with_fathers --show
+
Some useful configuration pathes
=================================
**pip mode for python modules**
+This new mode was introduced in order to simplify the management of the python products (which number is constantly raising years after years...)
+It is trigered by two properties within the application configuration file::
+
+ pip : 'yes'
+ pip_install_dir : 'python'
+
+The first property activates the use of pip for all the products which have themselves the pip property activated (it concerns twenty products).
+The second property specifies that the products should be installed directly in python directory, and not in their own specific directory.
+This second property is usefull on windows platform to reduce the length of python path.
+
+After several tests anf iterations, the following management was adopted:
+ - sat prepare <application> does nothing for pip products (because at prepare time we don't have python compiled, and the use of native pip may not be compatible).
+ - sat compile <application> use the pip module installed in python to get pip archives (wheels), store them in local archive directory, and install then either in python
+directory, or in the product directory (in accordance to pip_install_dir property).
+
**single directory mode**
+This new mode was introduced in order to get shorter path on windows platform. It is trigered by the property **single_install_dir** within the application configuration file::
+
+ single_install_dir : "yes"
+
+When activated, all the products which have themselves the property **single_install_dir** are installed in a common directory, called PRODUCTS.
**Generalisation of sat launcher command**
+sat launcher command was extended to generate lauchers based on an executable given as argument with **-e** option::
+
+ sat launcher <application> -n salome.sh -e INSTALL/SALOME/bin/salome.py
+
+The command generates a launcher called salome.sh, which set the environment, and launch the INSTALL/SALOME/bin/salome.py.
+
**optimisation of sat compile**
+For a complete compilation of salome, sat compile command was spending more than three minutes
+to calculate the dependencies and the order in which the products shoulb be compiled.
+The algorithm used was clumsy, and confused.
+It was therefore completely rewritten using a topological sorting.
+The products order calculation take now less than one second.
**new management of sections in product configution files**
+The sections defined in products are used to specify the variations in the way products are built.
+Depending upon the tag or version of the product, sat choose one of these sections and set the product definition according to it.
+With time, the number of sections increased a lot. And it is not easy to visualise the differences between these sections, as they often
+are identical, except few variations.
+With the windows version, new sections are introduced to manage windows specifics.
+
+Therefore the need of a new mode for managing sections arises, that would be simplier, more concise, and help the comprehension.
+This new mode is called **incremental**, and is trigered by the property **incremental** within the default section of the product::
+
+ default:
+ {
+ ....
+ properties:
+ {
+ incremental : "yes"
+ }
+ ...
+ }
+
+When this mode is defined, the definition of the product is defined incrementaly, by taking into account the reference (the default section) and applying to it corrections defined in the other incremental sections. Depending upon the case several sections may be taken into account, in a predefined order:
+
+* the default section, which contains the reference definition
+* on windows platform, the default_win section if it exists
+* the section corresponding to the tag. the algorithm to determine this section remains unchanged (what changes is that in incremental mode the section only define deltas, not the complete definition)
+* on windows platform, if it exists the same section posfiwed with "_win".
+
+Here is as an example the incremental definition used for boost products. For version 1.49 of boost, we extend the definition because we need to apply a patch::
+
+ default :
+ {
+ name : "boost"
+ build_source : "script"
+ compil_script : $name + $VARS.scriptExtension
+ get_source : "archive"
+ environ :
+ {
+ env_script : $name + ".py"
+ }
+ depend : ['Python' ]
+ opt_depend : ['openmpi' ]
+ patches : [ ]
+ source_dir : $APPLICATION.workdir + $VARS.sep + 'SOURCES' + $VARS.sep + $name
+ build_dir : $APPLICATION.workdir + $VARS.sep + 'BUILD' + $VARS.sep + $name
+ install_dir : 'base'
+ properties :
+ {
+ single_install_dir : "yes"
+ incremental : "yes"
+ }
+ }
+
+ version_1_49_0:
+ {
+ patches : [ "boost-1.49.0.patch" ]
+ }
+
+
Change log
----------
#evaluate = value.resolve(config)
aStream.write("<header>%s%s<reset> : %s <yellow>--> '%s'<reset>\n" % (indstr, path, config, str(config)))
except Exception as e:
- aStream.write("<header>%s%s<reset> : <red>!!! ERROR: %s !!!<reset>\n" % (indstr, path, e.message))
+ aStream.write("<header>%s%s<reset> : <red>!!! ERROR: %s !!!<reset>\n" % (indstr, path, str(e)))
return
'''
evaluate = value.evaluate(config)
aStream.write("%s%s.%s : %s --> '%s'\n" % (indstr, path, key, str(value), evaluate))
except Exception as e:
- aStream.write("%s%s.%s : !!! ERROR: %s !!!\n" % (indstr, path, key, e.message))
+ aStream.write("%s%s.%s : !!! ERROR: %s !!!\n" % (indstr, path, key, str(e)))
continue
if "Reference" in strType:
try:
evaluate = value.resolve(config)
aStream.write("%s%s.%s : %s --> '%s'\n" % (indstr, path, key, str(value), evaluate))
except Exception as e:
- aStream.write("%s%s.%s : !!! ERROR: %s !!!\n" % (indstr, path, key, e.message))
+ aStream.write("%s%s.%s : !!! ERROR: %s !!!\n" % (indstr, path, key, str(e)))
continue
if type(value) in [str, bool, int, type(None), unicode]:
aStream.write("%s%s.%s : '%s'\n" % (indstr, path, key, str(value)))
try:
aStream.write("!!! TODO fix that %s %s%s.%s : %s\n" % (type(value), indstr, path, key, str(value)))
except Exception as e:
- aStream.write("%s%s.%s : !!! %s\n" % (indstr, path, key, e.message))
+ aStream.write("%s%s.%s : !!! %s\n" % (indstr, path, key, str(e)))
if os.path.isfile(docfile):
out, err = subprocess.Popen(["xdg-open", docfile]).communicate()
else:
- print "Online documentation is not accessible for module:", module
+ print ("Online documentation is not accessible for module:", module)
else:
- print module+"_ROOT_DIR not found!"
+ print (module+"_ROOT_DIR not found!")
def main(args):
# Identify application path then locate configuration files
usage()
sys.exit(0)
- #from salomeContextUtils import getConfigFileNames
- #configFileNames, args, unexisting = getConfigFileNames( args, checkExistence=True )
- #if len(unexisting) > 0:
- # print "ERROR: unexisting configuration file(s): " + ', '.join(unexisting)
- # sys.exit(1)
# Create a SalomeContext which parses configFileNames to initialize environment
try:
