Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

edmPluginHelp: print the plugin type as well as the name and library #6373

Merged
merged 1 commit into from Nov 13, 2014

Conversation

fwyzard
Copy link
Contributor

@fwyzard fwyzard commented Nov 13, 2014

No description provided.

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @fwyzard (Andrea Bocci) for CMSSW_7_3_X.

edmPluginHelp: print the plugin type as well as the name and library

It involves the following packages:

FWCore/ParameterSet

@cmsbuild, @Dr15Jones, @ktf, @nclopezo can you please review it and eventually sign? Thanks.
@wddgit, @wmtan this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
@nclopezo you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

@Dr15Jones
Copy link
Contributor

+1

@fwyzard
Copy link
Contributor Author

fwyzard commented Nov 13, 2014

Hi,
actually I would like edmPludingHelp to be able to tell me if a module is classic EDProducer, a one::EDProducer, a stream::EDProducer, or a global::EDproducer, etc.

My first attempt to modify kBaseType in FWCore/Framework/src/global/EDAnalyzerBase.cc etc. has the problem that the same string is used to write the _cfi.py file.

Possible alternatives would be:

  • add one more field to each base class (e.g. kExtendedBaseType = "global::EDAnalyzer")
  • to set kBaseType = "global::EDAnalyzer" and filter out the global:: part when writing the cfi
  • try to infer the exact type at compile time instead of relying on a member variable

What would be the framework's preferred solution ?

@cmsbuild
Copy link
Contributor

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_3_X IBs unless changes or unless it breaks tests.

@Dr15Jones
Copy link
Contributor

You can actually get the list of 'legacy' module types from the static analyzer report run every day. E.g.
https://cmssdt.cern.ch/SDT/jenkins-artifacts/ib-static-analysis/CMSSW_7_3_X_2014-11-12-1400/slc6_amd64_gcc481/llvm-analysis/index.html
Look under the 'ThreadSafety' section for 'inherits from ...'.

If that is insufficient than my preference (in this order)

  1. figure out at compile time
  2. add another field to base class which returns an enum for kLegacy, kStream or kGlobal. Then the string you want could be made by composing the info from that enum with the other string.

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_3_X IBs unless changes (tests are also fine). This pull request will be automatically merged.

cmsbuild added a commit that referenced this pull request Nov 13, 2014
edmPluginHelp: print the plugin type as well as the name and library
@cmsbuild cmsbuild merged commit d651793 into cms-sw:CMSSW_7_3_X Nov 13, 2014
@cmsbuild
Copy link
Contributor

@fwyzard
Copy link
Contributor Author

fwyzard commented Nov 13, 2014

Hi Chris,
see #6383 .

.A

@fwyzard fwyzard deleted the edmPluginHelp_add_plugin_type branch December 23, 2014 10:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants