Community
Participate
Working Groups
Today ETFw launches the workflow steps in ToolLaunchManager's launchSAXTool or launchJAXBTool method. There is special processing to handle when some one checks either "Build the instrumented executable but do not launch it" (buildOnly flag) and/or "Select existing performance data to analyze with the selected tool" (analyzeOnly flag). As I understand it the intent of the build flag was to do all the processing before the exec/launch, and the second flag was to do all the processing after the exec/launch. However I have a problem. I have a workflow that contains an analyze step both before and after the exec/launch and things are getting messed up because of this ordering. The current algorithm finds the first analyze step before the exec/launch when it should instead have found the second one after the exec/launch. So I would like to propose changing the algorithm it uses to find the build steps and the analyze steps. Instead of searching for the first build step and the first analyze step it would search for the exec/launch step and then treat all steps before the exec/launch as 'build' steps (regardless of type), and all steps after the exec/launch as 'analyze' steps (regardless of type). This solves the problem for me, but my main concern is that this may negatively affect TAU. What do you think?
I believe this is an issue that needs to be addressed but there are some complications that mean the logic will be a little more involved. Specifically, there are workflows that have multiple execute steps, build might be the first build before any execute and 'manage data' might be the steps after the last execute. A catch-all might be to allow the tool definition itself to indicate which steps are build and which are data management, but that requires a little more attention from tool integrators which I'm not sure is necessary.
Thanks so much Wyatt for your comments. There is an alternative solution that I've been thinking about. We can use the new tool-state conditional execution. The check box setting of "Build the instrumented executable but do not launch it" (buildOnly flag) and/or "Select existing performance data to analyze with the selected tool" (analyzeOnly flag) actually set a launch configuration attribute of "build_but_do_not_run_instrumented_executable" and "analyze_existing_perf_data_in_specified_location_build/run_nothing" respectively. For example, we could add the following to all non-build-only steps (negative logic) <tool-state> <do-execute-if attribute="build_but_do_not_run_instrumented_executable"> </tool-state> This would allow the workflow developer to have full control of what does or does not get executed when these check boxes are checked. There would be no assumption then of what first build step or before exec step, etc. mean. Side-point: The attribute names could be changed to make them a bit easier to work with. What do you think?
This would mean that all the special processing in the ToolLaunchManager would be removed to just the current general processing for-loop making that code much much simpler.
