[cmake-developers] Developer tasks - Refactoring

Daniel Pfeifer daniel at pfeifer-mail.de
Mon Jun 6 17:14:56 EDT 2016


On Sun, Jun 5, 2016 at 2:15 PM, Stephen Kelly <steveire at gmail.com> wrote:
> On 05/19/2016 11:27 PM, Daniel Pfeifer wrote:
>> On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly <steveire at gmail.com> wrote:
>>> 1) Make cmLocalGenerator not inherit cmOutputConverter
>>> * Change enums like cmLocalGenerator::START_OUTPUT with sed.  See
>>>
>>>    https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eac15298
>>>
>>>   for a similar sed command to achieve this.
>>>
>>> * Remove inheritance. Implement Convert() methods in cmLocalGenerator for
>>>   source compatibility which instantiate and use a cmOutputConverter as in
>>>
>>>    https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d8b79ad
>> That may change behavior because the LinkScriptShell member may have
>> the wrong value.
>> I am currently digging deeper.
>
> Yes, that looks like it requires deeper digging.
>
> In commit v3.3.0-rc1~29^2~1 (cmState: Host some state from the
> cmGlobalGenerator., 2015-05-24) I moved other things which are used by
> Convert() APIs to cmState, but the LinkScriptShell didn't seem to belong
> there.
>
> I was hoping the callers which need LinkScriptShell would manage that
> state themselves somehow, but it would take some deep digging and
> probably refactoring of the makefile generator to do that.
>
> Did your digging turn anything up?

Here is what I found.

* GetFortranFormat is called with an object, even though it is a
static member function. (That is easy to refactor.)
* SetLinkScriptShell is called from two places:
cmMakefileExecutableTargetGenerator::WriteExecutableRule and
cmMakefileLibraryTargetGenerator::WriteLibraryRules.
* We can instantiate a cmOutputConverter in those places and then pass
it along the call tree in all branches that contain calls to Convert.
* Doxygen's call-graphs and caller-graphs are not reliable. Doxygen
sometimes lies.


More information about the cmake-developers mailing list