Who wins on private/no_auto_import use statements?

[/C=FR/O=CNRS/OU=UMR8607/CN=Vincent Garonne/emailAddress=garonne@…]

If I have the following situation:

PkgA:

use PkgB * use PkgC *

PkgB:

use PkgD * -no_auto_imports

PkgC:

use PkgD *

PkgD:

macro PkgD_macro "foo" [etc.]

Should I expect that PkgA would see any paths & macros defined by PkgD or not? What about if I interchange the use statements in PkgA?

Similarly if PkgC has:

PkgC:

private use PkgD *

Would I expect to see the contributions from PkgD in PkgA?

The reason I'm asking this is to try to understand some problems that I'm seeing from the InnerDetector/InDetAlignTools/SiRobustAlignTools and InnerDetector/InDetExample/InDetExtrapolationExample packages (these are both in AtlasReconstruction,rel_3).

In the first case, if I look for the EventInfo package I see:

dquarrie@…> cmt show uses | grep EventInfo # use EventInfo EventInfo-00-* Event (no_version_directory) # use EventInfo EventInfo-* Event (no_version_directory) # use EventInfo EventInfo-00-* Event (no_version_directory) # use EventInfo EventInfo-00-* Event (no_version_directory) # use EventInfo EventInfo-* Event (private) (no_version_directory) use EventInfo EventInfo-00-04-05 Event (/afs/cern.ch/atlas/software/builds/nightlies/dev/AtlasCore/rel_3/)

If I now look at the contribution to use_linkopts from EventInfo I see:

dquarrie@…> cmt show macro use_linkopts | grep EventInfo

So even though EventInfo is used publically for most of the dependency tree, it looks like it's treated as being private and it's macros are not exported.

For the case of InDetExtrapolationExample I see:

dquarrie@…> cmt show uses | grep EventInfo # use EventInfo EventInfo-00-* Event (no_version_directory) # use EventInfo EventInfo-* Event (no_version_directory) # use EventInfo EventInfo-00-* Event (no_version_directory) # use EventInfo EventInfo-00-* Event (no_version_directory) use EventInfo EventInfo-00-04-05 Event (/afs/cern.ch/atlas/software/builds/nightlies_slc4/dev/AtlasCore/rel_3/) (no_auto_imports) dquarrie@…>

So the last usage of it was in no_auto_imports mode (actually since CMT gives up showing the complete dependency tree you don't see where that is, but it was actually from AtlasReconstructionRunTime, which happens to be early in the requirements file:

use AtlasPolicy AtlasPolicy-01-* use GaudiInterface GaudiInterface-01-* External use AtlasAIDA AtlasAIDA-00-* External

use AtlasReconstructionRunTime AtlasReconstructionRunTime-*

use TrkDetDescrTools TrkDetDescrTools-00-* Tracking/TrkDetDescr [etc.]

Again, if I look at the contribution from EventInfo I see:

dquarrie@…> cmt show macro use_linkopts | grep EventInfo dquarrie@…>

If I now move that use statement to the end of the list I see the expected contribution from EventInfo.

This raises the question of what the logic should be in either case. I would have thought that any public usage (that is reachable from the present package) should override the effect of either a private usage, or a no_auto_imports one further down the dependency tree.

[/C=FR/O=CNRS/OU=UMR8607/CN=Vincent Garonne/emailAddress=garonne@…]

Scenario to reproduce the problem

[/C=FR/O=CNRS/OU=UMR8607/CN=Vincent Garonne/emailAddress=garonne@…]

If I have the following situation:

PkgA:

use PkgB * use PkgC *

PkgB:

use PkgD * -no_auto_imports

PkgC:

use PkgD *

PkgD:

macro PkgD_macro "foo" [etc.]

Should I expect that PkgA would see any paths & macros defined by PkgD or not?

Just a quick remembered (also for me;)):The -no_auto_imports option suppresses the automatic inheritance of some standard parameters from the specified used packages. A (non-exhaustive) list of these options is: <package >_cflags, <package >_pp_cflags, <package >_cppflags , <package >_pp_cppflags, <package >_fflags, <package>_pp_fflags, <package >_libraries, <package >_linkopts, <package >_stamps , <package >_native_version, <package>_export_paths, <package >_home

I've implemented you scenario (tarball in attachment, command to use: tar -xvzf pffff.tar.gz; cd workarea/; cmt config)

the answer is actually yes. The package PkgA sees the macros and paths defined by PkgD. PkgA:

use PkgB * use PkgC * macro PkgA_macro ${PkgD_root} macro PkgA_macro2 ${PkgD_macro}

cmt show macro_value PkgA_macro

/Users/garonne/EspaceDeTravail/workarea/PkgD/v1

cmt show macro_value PkgA_macro2

foo

cmt show macros | grep PkgD

PkgD_tag='$(tag)' PKGDROOT='/Users/garonne/EspaceDeTravail/workarea/PkgD/v1' PkgD_root='/Users/garonne/EspaceDeTravail/workarea/PkgD/v1' PkgD_cmtpath='/Users/garonne/EspaceDeTravail/workarea' PkgD_project='EspaceDeTravail' PkgD_project_release='workarea' PkgD_macro='foo' PkgB_macro='${PkgD_root}' PkgB_macro2='${PkgD_macro}' PkgA_macro='${PkgD_root}' PkgA_macro2='${PkgD_macro}' use_linkopts=' $(cmt_installarea_linkopts) $(PkgA_linkopts) $(PkgB_linkopts) $(PkgC_linkopts) $(PkgD_linkopts) ' use_includes=' $(ppcmd)"$(PkgB_root)/src" $(ppcmd)"$(PkgC_root)/src" $(ppcmd)"$(PkgD_root)/src" ' use_stamps=' $(PkgA_stamps) $(PkgB_stamps) $(PkgC_stamps) $(PkgD_stamps) ' use_cflags=' $(PkgA_cflags) $(PkgB_cflags) $(PkgC_cflags) $(PkgD_cflags) ' use_pp_cflags=' $(PkgA_pp_cflags) $(PkgB_pp_cflags) $(PkgC_pp_cflags) $(PkgD_pp_cflags) ' use_cppflags=' $(PkgA_cppflags) $(PkgB_cppflags) $(PkgC_cppflags) $(PkgD_cppflags) ' use_pp_cppflags=' $(PkgA_pp_cppflags) $(PkgB_pp_cppflags) $(PkgC_pp_cppflags) $(PkgD_pp_cppflags) ' use_fflags=' $(PkgA_fflags) $(PkgB_fflags) $(PkgC_fflags) $(PkgD_fflags) ' use_pp_fflags=' $(PkgA_pp_fflags) $(PkgB_pp_fflags) $(PkgC_pp_fflags) $(PkgD_pp_fflags) ' use_libraries=' $(PkgB_libraries) $(PkgC_libraries) $(PkgD_libraries) '

What about if I interchange the use statements in PkgA?

I suppose: PkgA:

use PkgC * use PkgB *

Yes, it is still working. We have the same behavior

Similarly if PkgC has:

PkgC:

private use PkgD *

Would I expect to see the contributions from PkgD in PkgA?

You will see only the non standart macros:

cmt show macros | grep PkgDPkgD_tag='$(tag)'

PKGDROOT='/Users/garonne/EspaceDeTravail/workarea/PkgD/v1' PkgD_root='/Users/garonne/EspaceDeTravail/workarea/PkgD/v1' PkgD_cmtpath='/Users/garonne/EspaceDeTravail/workarea' PkgD_project='EspaceDeTravail' PkgD_project_release='workarea' PkgD_macro='foo' PkgB_macro='${PkgD_root}' PkgB_macro2='${PkgD_macro}' PkgA_macro='${PkgD_root}' PkgA_macro2='${PkgD_macro}' use_stamps=' $(PkgA_stamps) $(PkgC_stamps) $(PkgB_stamps) $(PkgD_stamps) ' use_libraries=' $(PkgC_libraries) $(PkgB_libraries) $(PkgD_libraries) '

In our case, to determine the difference just go in the PkgC and PkgB packages and execute cmt show macros | grep PkgD, you will see the different macros exported:

PkgC:

cmt show macros | grep PkgD

PkgD_tag='$(tag)' PKGDROOT='/Users/garonne/EspaceDeTravail/workarea/PkgD/v1' PkgD_root='/Users/garonne/EspaceDeTravail/workarea/PkgD/v1' PkgD_cmtpath='/Users/garonne/EspaceDeTravail/workarea' PkgD_project='EspaceDeTravail' PkgD_project_release='workarea' PkgD_macro='foo' use_linkopts=' $(cmt_installarea_linkopts) $(PkgC_linkopts) $(PkgD_linkopts) ' use_includes=' $(ppcmd)"$(PkgD_root)/src" ' use_stamps=' $(PkgC_stamps) $(PkgD_stamps) ' use_cflags=' $(PkgC_cflags) $(PkgD_cflags) ' use_pp_cflags=' $(PkgC_pp_cflags) $(PkgD_pp_cflags) ' use_cppflags=' $(PkgC_cppflags) $(PkgD_cppflags) ' use_pp_cppflags=' $(PkgC_pp_cppflags) $(PkgD_pp_cppflags) ' use_fflags=' $(PkgC_fflags) $(PkgD_fflags) ' use_pp_fflags=' $(PkgC_pp_fflags) $(PkgD_pp_fflags) ' use_libraries=' $(PkgD_libraries) '

PkgB:

cmt show macros | grep PkgD

PkgD_tag='$(tag)' PKGDROOT='/Users/garonne/EspaceDeTravail/workarea/PkgD/v1' PkgD_root='/Users/garonne/EspaceDeTravail/workarea/PkgD/v1' PkgD_cmtpath='/Users/garonne/EspaceDeTravail/workarea' PkgD_project='EspaceDeTravail' PkgD_project_release='workarea' PkgD_macro='foo' PkgB_macro='${PkgD_root}' PkgB_macro2='${PkgD_macro}' use_stamps=' $(PkgB_stamps) $(PkgD_stamps) ' use_libraries=' $(PkgD_libraries) '

[/C=FR/O=CNRS/OU=UMR8607/CN=Vincent Garonne/emailAddress=garonne@…]

Dear Vincent, We have the following case in LHCb packages: Several packages make

use GSL v* LCG_Interfaces

All these packages are used by one which makes

use GSL v* LCG_Interfaces -no_auto_imports library mypackage ../src/*.cpp -import=GSL

Then

cmt sh uses

show GSL used without _no_auto_imports

cmt sh macro mypackage_use_linkopts

mypackage_use_linkopts undefined

If I declare GSL as no_auto_imports in all packages which use it

Then

cmt sh uses

show GSL used with -no_auto_imports

cmt sh macro mypackage_use_linkopts

mypackage_use_linkopts is properly defined

If I remove the -no_auto_imports from the use GSL

Then

cmt sh macro mypackage_use_linkopts is defined

Do you understand this behaviour? Could you explain how/when to use safely the -no_auto_imports

Many thanks Florence

[/C=FR/O=CNRS/OU=UMR8607/CN=Vincent Garonne/emailAddress=garonne@…]

Florence,

Indeed, we found and reported similar problems (also with a mixture of public/private "use" statements). The short term fix we've found so far is to juggle the ordering of the use statements in the package (or packages) that form the top of the of the two branches of the diamond (one branch has the -no_auto_imports and the other doesn't).

David

[/C=FR/O=CNRS/OU=UMR8607/CN=Vincent Garonne/emailAddress=garonne@…]

Hi,

I also have observed this problem. In my case it was related to

the fact that in package I have

library mypackage ../src/*.cpp -import=GSL

I must have the use of GSL with -no_auto_imports otherwise the macro mypackage_use_linkopts will be undefined.

Pere

[/C=FR/O=CNRS/OU=UMR8607/CN=Vincent Garonne/emailAddress=garonne@…]

Scenario to reproduce the problem from Florence example

[/C=FR/O=CNRS/OU=UMR8607/CN=Vincent Garonne/emailAddress=garonne@…]

I attach a new scenario from Florence's example which supposes to resume the all:

tar -xvzf scenario-ticket45-2.tar.gz 
cd P1/Pkg4/v1/cmt
cmt show macro Pkg4_use_linkopts

[/C=FR/O=CNRS/OU=UMR8607/CN=Vincent Garonne/emailAddress=garonne@…]

Hi,

I think that is due to the fact that we do not update the first registered use by the characteristics,e.g. auto-imports field, of another encountered with the same requirements. I've just done the update when we are in this case and apparently it works with the Florence's scenario. I will more test it.

Vincent.

[/C=FR/O=CNRS/OU=UMR8607/CN=Vincent Garonne/emailAddress=garonne@…]

fixed since v1r20