Re: [cmake-developers] Developer tasks - Refactoring

2016-09-07 Thread Stephen Kelly 
Daniel Pfeifer wrote:

> On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly
>  wrote:
>> 3) Compute cmGeneratorTarget state non-lazily in its constructor.
>> * Historically target state for generators was computed lazily because it
>>   might need to be cleared and re-computed.  That is no-longer true.
> 
> SourceFilesMap is cleared in a call to AddSource. It is then
> recomputed the next time GetSourceFiles is called.

Hmm, maybe there is a way to reduce the amount of times it is cleared, once 
the computation sequence is better defined by being extracted to 
cmComputeTarget. cmGeneratorTarget::AddSource is currently called from 
several generate-time locations, some of which could become compute-time 
locations. The uses in 

* cmQtAutoGeneratorInitializer::InitializeAutogenSources 
* cmGlobalVisualStudio8Generator::AddCheckTarget
* cmLocalVisualStudio7Generator::CreateVCProjBuildRule
* cmGlobalXCodeGenerator

seem that way to me, because the file names don't depend on anything from 
the cmGeneratorTarget which is only known at build time. Unless I'm missing 
something, they could be added to the list of files for the cmComputeTarget  
at compute time before the SourceFilesMap is populated at generate time.

The tricky case is when AddSource is called with something computed from the 
result of cmGeneratorTarget::GetSources. The only case of that seems to be 
SetupSourceFiles in cmQtAutoGeneratorInitializer. That calls AddSource in a 
loop. If cmComputeTarget gains an AddSource and doesn't have a 
SourceFilesMap, then that would be the only use of 
cmGeneratorTarget::AddSource. That could then be replaced with a new 
AddSources or AddSourcesForRCC, or something better might be possible.

This is just a brain-dump which I haven't investigated. You might find some 
facts which make the source addition refactoring to compute time to be 
impossible.

Then maybe the entries of the ComputedTargets map might not have to be 
recomputed lazily.

> Please review:
> https://github.com/purpleKarrot/CMake/commits/computed-target

Cool, thanks for working on this!

I am a bit confused by the first commit in the branch. It removes some c++ 
template code while adding cmComputeTarget. I think that's because you make 
the working class inherit from cmComputeTarget, and you do that just to re-
use the data members, and then later in the branch, to re-use the 
cmComputeTarget itself.

Is it possible to split what is happening in that commit? Is it possible to 
remove the template code first without introducing cmComputeTarget? Even if 
doing so would mean introducing a struct with the same data members early in 
the branch and perhaps removing that struct later, I think it might make the 
commit more clear. Currently I don't understand it.

I also generally recommend to put the most obvious/cleanup commits at the 
start of the branch (or even in a separate minor-cleanups branch). The 
'don't clear container in destructor' commit and the 'use erase-unique 
instead of reinitialization' commit and the 'factor out common part of 
AddSources commands' all seem to fit that description. I was able to rebase 
them at least, but I didn't try building the result. 

Getting those kinds of commits out of the way first makes the rest of the 
branch smaller and focused on extending the code in only one specific way.

Thanks,

Steve.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Developer tasks - Refactoring

2016-09-07 Thread Daniel Pfeifer 
On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly  wrote:
> 3) Compute cmGeneratorTarget state non-lazily in its constructor.
> * Historically target state for generators was computed lazily because it
>   might need to be cleared and re-computed.  That is no-longer true.

SourceFilesMap is cleared in a call to AddSource. It is then
recomputed the next time GetSourceFiles is called.

> * For example, the LinkInformation is populated lazily in
>   cmGeneratorTarget::GetLinkInformation.
> * Instead the LinkInformation could be populated in the cmGeneratorTarget
>   constructor for all known configurations.  That is what generators will
>   request during generate-time anyway.
> * Doing this will make it possible to split a cmComputedTarget out of
>   cmGeneratorTarget.

I started splitting out a cmComputedTarget. It is initialized in its
constructor for one single configuration.
The entries of the ComputedTargets map are computed and recomputed
lazily because of the reason mentioned above.

Please review: https://github.com/purpleKarrot/CMake/commits/computed-target
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Developer tasks - Refactoring

2016-06-06 Thread Stephen Kelly 
On 06/06/2016 11:14 PM, Daniel Pfeifer wrote:
> Here is what I found.
>
> * 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.

I don't think that's the right approach. It just worsens spaghetti code
and an antipattern in CMake which is already too widespread.

Stepping back a bit to look at the more general problem in CMake:

It is fairly common in CMake code to have methods used throughout the
codebase which take parameters and then use the parameters in if()
conditions to change the behavior of the method in significant ways.

This is an anti-pattern and a code smell. It couples all code which
calls the method and makes it harder to refactor, as you now see with
Convert(). It violates:

 https://en.wikipedia.org/wiki/Interface_segregation_principle

I fixed some of the instances of it in my
15-years-worth-of-cmake-clean-up-in-9-months last year.

Unfortunately because it is so common in CMake, this pattern still grows
in the codebase. See eg cmake::GetSuppressDeprecatedWarnings and related
methods which take a cmMakefile which defaults to null. Those methods
exist since v3.5.0-rc1~165^2 (Explicitly enable deprecated warnings by
default., 2015-11-29).

Notice how there is only ONE caller where the cmMakefile is not-null!

So it makes sense to take the condition out of the inside of the method
and put it in the call site. It simplifies everything:

 
https://github.com/steveire/CMake/commit/86d13501f3253c5489b8f6abf21b6a983481a77c

I didn't manage to get enough interest in that commit or the rest of the
branch to get it merged:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607

but I would like your review of the branch if you have time.

Anyway, back to Convert()...

The reason I listed this refactoring of removal of cmOutputConverter as
a base of cmLocalGenerator in the OP of this thread is to create
separation of compute-time code from generate-time code. So let's keep
that in mind as a goal.

Generate time should be just for generating. If we have that strict
design, it benefits the daemon because that needs to configure and
compute, and it benefits a multi-toolchain feature architecture because
that needs to configure for multiple toolchains, compute across the
result and then generate once (I'm talking about an idea evolved from
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272 in
case you never followed that).

Notice that Convert() is called at configure time, compute time and
generate time currently.

In the very end:

1) It should only be called at configure and compute time
2) CMake should create some state at compute time using APIs similar to
Convert()
3) Configure-time and compute-time Convert() behavior and APIs will not
necessarily be the same because the needs are different - you will see
that if you analyze the users of the Convert method and the OutputFormat
enum.

So, look into the Convert() methods. There are two overloads. Both do
some computation, then call ConvertToOutputFormat().

What does ConvertToOutputFormat() do? It does nothing at all if the
OutputFormat is UNCHANGED.

What is the default value of OutputFormat? It is UNCHANGED!

I guess you can see where this is going:

1) The parts of Convert() which come before the ConvertToOutputFormat()
calls should be extracted into two new overloads, maybe called
RawConvert(). The name is not great, but in the end the existing
Convert() methods can probably be deleted and the Raw* ones renamed.
2) Convert() should call RawConvert() and pass the result to
ConvertToOutputFormat().
3) Callers of Convert() should be ported to RawConvert(). A quick way to
do most of this is to find all callers of Convert() which pass only two
arguments and change those to RawConvert(). Note that there are other
callers which explicitly pass UNCHANGED!
4) Analyze remaining callers of Convert() and inspect the OutputFormat
they pass. For example see the output of 'git grep -w RESPONSE'. That
enum value can probably be removed and the EscapeForShell inlined into
the callers.
5) Do the same analysis for the other enum values. SHELL is used a lot.
In the end some new method might make sense for the SHELL case instead
of that enum.
6) Look at the result and see if there is an obvious way to go from
here, including for the LinkScriptShell case. The case where that
condition is used might be the last remaining case when the above is
done, and a different design can be considered.
7) The OutputFormat enum and the LinkScriptShell can probably be removed
in the end, with their callers ported to more-purposeful methods.

The whole point of this is to reach the essence of what all this
Convert() stuff in CMake is really about. It's currently very confused
and fixing that

Re: [cmake-developers] Developer tasks - Refactoring

2016-06-06 Thread Daniel Pfeifer 
On Sun, Jun 5, 2016 at 2:15 PM, Stephen Kelly  wrote:
> On 05/19/2016 11:27 PM, Daniel Pfeifer wrote:
>> On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly  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.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Developer tasks - Refactoring

2016-06-05 Thread Stephen Kelly 
On 05/19/2016 11:27 PM, Daniel Pfeifer wrote:
> On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly  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?

Thanks,

Steve.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Developer tasks - Refactoring

2016-06-05 Thread Stephen Kelly 
On 05/20/2016 12:06 AM, Daniel Pfeifer wrote:
> On Thu, May 19, 2016 at 11:18 PM Daniel Pfeifer
> > wrote:
>
> On Wed, Feb 10, 2016 at 12:15 AM Stephen Kelly  > wrote:
>
> 1) Make cmLocalGenerator not inherit cmOutputConverter
> * Change enums like cmLocalGenerator::START_OUTPUT with sed.  See
>
>
> Please see attached patch.
>
>
> Revised patch attached. Please ignore the previous one.
> This one also fully qualifies the enums that were used unqualified.

Thanks for working on this! Looks good to me too.

Steve.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Developer tasks - Refactoring

2016-05-23 Thread Brad King 
On 05/19/2016 06:06 PM, Daniel Pfeifer wrote:
>>> 1) Make cmLocalGenerator not inherit cmOutputConverter
>>>  * Change enums like cmLocalGenerator::START_OUTPUT with sed.  See
> Revised patch attached. Please ignore the previous one.
> This one also fully qualifies the enums that were used unqualified.

Thanks.  Please merge to 'next' for testing.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Developer tasks - Refactoring

2016-05-19 Thread Daniel Pfeifer 
On Thu, May 19, 2016 at 11:18 PM Daniel Pfeifer 
wrote:

> On Wed, Feb 10, 2016 at 12:15 AM Stephen Kelly  wrote:
>
>> 1) Make cmLocalGenerator not inherit cmOutputConverter
>> * Change enums like cmLocalGenerator::START_OUTPUT with sed.  See
>
>
> Please see attached patch.
>

Revised patch attached. Please ignore the previous one.
This one also fully qualifies the enums that were used unqualified.
From d955e4257faae1cd5b6a1fc300583d74dce6c061 Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer 
Date: Thu, 19 May 2016 23:11:40 +0200
Subject: [PATCH] Use enums defined in cmOutputConverter using their fully
 qualified name.

Mostly automated:

values=("RelativeRoot" "NONE" "FULL" "HOME" "START" "HOME_OUTPUT" "START_OUTPUT"
"OutputFormat" "UNCHANGED" "MAKERULE" "SHELL" "WATCOMQUOTE" "RESPONSE"
"FortranFormat" "FortranFormatNone" "FortranFormatFixed" "FortranFormatFree")
for i in "${values[@]}"; do git grep -l cmLocalGenerator::$i | xargs sed -i "s|cmLocalGenerator::$i|cmOutputConverter::$i|g"; done
---
 Source/cmCommonTargetGenerator.cxx |  18 ++--
 Source/cmCommonTargetGenerator.h   |   4 +-
 Source/cmDependsC.cxx  |  10 +--
 Source/cmDependsFortran.cxx|  40 -
 Source/cmExtraEclipseCDT4Generator.cxx |   2 +-
 Source/cmGlobalGenerator.cxx   |   2 +-
 Source/cmGlobalNinjaGenerator.cxx  |  10 +--
 Source/cmGlobalUnixMakefileGenerator3.cxx  |  24 ++---
 Source/cmGlobalVisualStudio7Generator.cxx  |   2 +-
 Source/cmGlobalXCodeGenerator.cxx  |   8 +-
 Source/cmLocalGenerator.cxx|   2 +-
 Source/cmLocalGenerator.h  |  12 +--
 Source/cmLocalNinjaGenerator.cxx   |  27 +++---
 Source/cmLocalNinjaGenerator.h |  12 +--
 Source/cmLocalUnixMakefileGenerator3.cxx   | 106 --
 Source/cmLocalUnixMakefileGenerator3.h |  12 +--
 Source/cmLocalVisualStudio7Generator.cxx   |  41 +
 Source/cmMakefileExecutableTargetGenerator.cxx |  55 ++--
 Source/cmMakefileLibraryTargetGenerator.cxx|  84 +-
 Source/cmMakefileTargetGenerator.cxx   | 118 -
 Source/cmMakefileUtilityTargetGenerator.cxx|   4 +-
 Source/cmNinjaNormalTargetGenerator.cxx|  22 ++---
 Source/cmNinjaTargetGenerator.cxx  |  12 +--
 Source/cmNinjaUtilityTargetGenerator.cxx   |   4 +-
 Source/cmVisualStudio10TargetGenerator.cxx |   4 +-
 25 files changed, 333 insertions(+), 302 deletions(-)

diff --git a/Source/cmCommonTargetGenerator.cxx b/Source/cmCommonTargetGenerator.cxx
index 6b2d1e3..c630971 100644
--- a/Source/cmCommonTargetGenerator.cxx
+++ b/Source/cmCommonTargetGenerator.cxx
@@ -43,8 +43,8 @@ std::string const& cmCommonTargetGenerator::GetConfigName() const
 }
 
 std::string cmCommonTargetGenerator::Convert(
-  std::string const& source, cmLocalGenerator::RelativeRoot relative,
-  cmLocalGenerator::OutputFormat output)
+  std::string const& source, cmOutputConverter::RelativeRoot relative,
+  cmOutputConverter::OutputFormat output)
 {
   return this->LocalGenerator->Convert(source, relative, output);
 }
@@ -140,7 +140,7 @@ void cmCommonTargetGenerator::AddFortranFlags(std::string& flags)
   std::string mod_dir = this->GetFortranModuleDirectory();
   if (!mod_dir.empty()) {
 mod_dir =
-  this->Convert(mod_dir, this->WorkingDirectory, cmLocalGenerator::SHELL);
+  this->Convert(mod_dir, this->WorkingDirectory, cmOutputConverter::SHELL);
   } else {
 mod_dir =
   this->Makefile->GetSafeDefinition("CMAKE_Fortran_MODDIR_DEFAULT");
@@ -167,7 +167,7 @@ void cmCommonTargetGenerator::AddFortranFlags(std::string& flags)
  idi != includes.end(); ++idi) {
   std::string flg = modpath_flag;
   flg +=
-this->Convert(*idi, cmLocalGenerator::NONE, cmLocalGenerator::SHELL);
+this->Convert(*idi, cmOutputConverter::NONE, cmOutputConverter::SHELL);
   this->LocalGenerator->AppendFlags(flags, flg);
 }
   }
@@ -177,18 +177,18 @@ void cmCommonTargetGenerator::AppendFortranFormatFlags(
   std::string& flags, cmSourceFile const& source)
 {
   const char* srcfmt = source.GetProperty("Fortran_FORMAT");
-  cmLocalGenerator::FortranFormat format =
+  cmOutputConverter::FortranFormat format =
 this->LocalGenerator->GetFortranFormat(srcfmt);
-  if (format == cmLocalGenerator::FortranFormatNone) {
+  if (format == cmOutputConverter::FortranFormatNone) {
 const char* tgtfmt = this->GeneratorTarget->GetProperty("Fortran_FORMAT");
 format = this->LocalGenerator->GetFortranFormat(tgtfmt);
   }
   const char* var = 0;
   switch (format) {
-case cmLocalGenerator::FortranFormatFixed:
+case cmOutputConverter::FortranFormatFixed:
   var = "CMAKE_Fortran_FORMAT_FIXED_FLAG";
   break;
-case

Re: [cmake-developers] Developer tasks - Refactoring

2016-05-19 Thread Daniel Pfeifer 
On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly  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.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Developer tasks - Refactoring

2016-05-19 Thread Daniel Pfeifer 
On Wed, Feb 10, 2016 at 12:15 AM Stephen Kelly  wrote:

> 1) Make cmLocalGenerator not inherit cmOutputConverter
> * Change enums like cmLocalGenerator::START_OUTPUT with sed.  See


Please see attached patch.
From 9e1203308ad79d62b24fe6930501e1013b4e52ec Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer 
Date: Thu, 19 May 2016 23:11:40 +0200
Subject: [PATCH] Use enums defined in cmOutputConverter using their fully
 qualified name.

Mostly automated:

values=("RelativeRoot" "NONE" "FULL" "HOME" "START" "HOME_OUTPUT" "START_OUTPUT"
"OutputFormat" "UNCHANGED" "MAKERULE" "SHELL" "WATCOMQUOTE" "RESPONSE"
"FortranFormat" "FortranFormatNone" "FortranFormatFixed" "FortranFormatFree")
for i in "${values[@]}"; do git grep -l cmLocalGenerator::$i | xargs sed -i "s|cmLocalGenerator::$i|cmOutputConverter::$i|g"; done
---
 Source/cmCommonTargetGenerator.cxx |  18 ++--
 Source/cmCommonTargetGenerator.h   |   4 +-
 Source/cmDependsC.cxx  |  10 +--
 Source/cmDependsFortran.cxx|  40 -
 Source/cmExtraEclipseCDT4Generator.cxx |   2 +-
 Source/cmGlobalGenerator.cxx   |   2 +-
 Source/cmGlobalNinjaGenerator.cxx  |  10 +--
 Source/cmGlobalUnixMakefileGenerator3.cxx  |  24 ++---
 Source/cmGlobalVisualStudio7Generator.cxx  |   2 +-
 Source/cmGlobalXCodeGenerator.cxx  |   8 +-
 Source/cmLocalGenerator.cxx|   2 +-
 Source/cmLocalGenerator.h  |  12 +--
 Source/cmLocalUnixMakefileGenerator3.cxx   |  50 +--
 Source/cmLocalUnixMakefileGenerator3.h |   6 +-
 Source/cmLocalVisualStudio7Generator.cxx   |  16 ++--
 Source/cmMakefileExecutableTargetGenerator.cxx |  55 ++--
 Source/cmMakefileLibraryTargetGenerator.cxx|  84 +-
 Source/cmMakefileTargetGenerator.cxx   | 118 -
 Source/cmMakefileUtilityTargetGenerator.cxx|   4 +-
 Source/cmNinjaNormalTargetGenerator.cxx|  22 ++---
 Source/cmNinjaTargetGenerator.cxx  |  12 +--
 Source/cmNinjaUtilityTargetGenerator.cxx   |   4 +-
 Source/cmVisualStudio10TargetGenerator.cxx |   4 +-
 23 files changed, 257 insertions(+), 252 deletions(-)

diff --git a/Source/cmCommonTargetGenerator.cxx b/Source/cmCommonTargetGenerator.cxx
index 6b2d1e3..c630971 100644
--- a/Source/cmCommonTargetGenerator.cxx
+++ b/Source/cmCommonTargetGenerator.cxx
@@ -43,8 +43,8 @@ std::string const& cmCommonTargetGenerator::GetConfigName() const
 }
 
 std::string cmCommonTargetGenerator::Convert(
-  std::string const& source, cmLocalGenerator::RelativeRoot relative,
-  cmLocalGenerator::OutputFormat output)
+  std::string const& source, cmOutputConverter::RelativeRoot relative,
+  cmOutputConverter::OutputFormat output)
 {
   return this->LocalGenerator->Convert(source, relative, output);
 }
@@ -140,7 +140,7 @@ void cmCommonTargetGenerator::AddFortranFlags(std::string& flags)
   std::string mod_dir = this->GetFortranModuleDirectory();
   if (!mod_dir.empty()) {
 mod_dir =
-  this->Convert(mod_dir, this->WorkingDirectory, cmLocalGenerator::SHELL);
+  this->Convert(mod_dir, this->WorkingDirectory, cmOutputConverter::SHELL);
   } else {
 mod_dir =
   this->Makefile->GetSafeDefinition("CMAKE_Fortran_MODDIR_DEFAULT");
@@ -167,7 +167,7 @@ void cmCommonTargetGenerator::AddFortranFlags(std::string& flags)
  idi != includes.end(); ++idi) {
   std::string flg = modpath_flag;
   flg +=
-this->Convert(*idi, cmLocalGenerator::NONE, cmLocalGenerator::SHELL);
+this->Convert(*idi, cmOutputConverter::NONE, cmOutputConverter::SHELL);
   this->LocalGenerator->AppendFlags(flags, flg);
 }
   }
@@ -177,18 +177,18 @@ void cmCommonTargetGenerator::AppendFortranFormatFlags(
   std::string& flags, cmSourceFile const& source)
 {
   const char* srcfmt = source.GetProperty("Fortran_FORMAT");
-  cmLocalGenerator::FortranFormat format =
+  cmOutputConverter::FortranFormat format =
 this->LocalGenerator->GetFortranFormat(srcfmt);
-  if (format == cmLocalGenerator::FortranFormatNone) {
+  if (format == cmOutputConverter::FortranFormatNone) {
 const char* tgtfmt = this->GeneratorTarget->GetProperty("Fortran_FORMAT");
 format = this->LocalGenerator->GetFortranFormat(tgtfmt);
   }
   const char* var = 0;
   switch (format) {
-case cmLocalGenerator::FortranFormatFixed:
+case cmOutputConverter::FortranFormatFixed:
   var = "CMAKE_Fortran_FORMAT_FIXED_FLAG";
   break;
-case cmLocalGenerator::FortranFormatFree:
+case cmOutputConverter::FortranFormatFree:
   var = "CMAKE_Fortran_FORMAT_FREE_FLAG";
   break;
 default:
@@ -244,7 +244,7 @@ std::string cmCommonTargetGenerator::GetFrameworkFlags(std::string const& l)
   if (emitted.insert(*i).second) {
 flags += fwSearchFlag;
 flags +=