Re: [cmake-developers] Eclipse CDT Managed build

2017-01-26 Thread Paul Smith 
IMO the right place for managing relocatable builds is in the
compiler/linker, not in the build tool.

The compiler/linker should provide options that allow the output to be
relocatable regardless of the contents of the command line.  GCC for
example has -fdebug-prefix-map that will allow you to remove prefixes
from pathnames in debug sections of the output.  Unfortunately this is
only part of the solution since it doesn't help with __FILE__ (for
example).  Nevertheless this is the right direction, rather than
modifying the build system.


On Thu, 2017-01-26 at 14:01 +, Bøe, Sebastian wrote:
> Thank you for the warning and support. We would prefer to not
> maintain
> a fork, but I have not been able to find any other technology
> that is suitable.
> 
> For future reference. The intended use-case is for CMake to act 
> as an engine in an IDE project generator solution similar to the
> below
> solutions[0].
> 
> [0] 
> http://start.atmel.com/
> http://www.st.com/en/embedded-software/stm32cube-embedded-software.ht
> ml
> 
> 
> 
> -Original Message-
> From: Brad King [mailto:brad.k...@kitware.com] 
> Sent: 26. januar 2017 14:18
> To: Bøe, Sebastian 
> Cc: ben.boec...@kitware.com; cmake-developers@cmake.org
> Subject: Re: [cmake-developers] Eclipse CDT Managed build
> 
> On 01/26/2017 05:57 AM, Bøe, Sebastian wrote:
> > 
> > I will investigate relocatable builds, because in spite of this
> > not 
> > being trivial, I think CMake still comes out as the best suited
> > technology for my use-case.
> 
> We once had an option to produce relative paths in the build system
> and it was a never ending mess of bugs.  Eventually it was ripped
> out.
> It is unlikely we will accept changes to try to re-introduce such an
> option.
> 
> -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] Code style auto-formatting

2016-05-09 Thread Paul Smith 
On Mon, 2016-05-09 at 14:17 -0400, Brad King wrote:
> > What is the rationale for "ColumnLimit: 79"? To make a line fit on old
> > school terminals, 80 should be OK. To make a diff or an email response
> > fit on old school terminals, two extra spaces are reserved. That leads
> > to a column limit of 78. Where does 79 come from?
> 
> That has been CMake's limit for a long time.  Since we're changing the
> style anyway we might as well go with the more common 80 chars that is
> default in the Mozilla style.

Not to say whether or not this should be changed, but FYI the 79 comes
from this set of facts:

 * Traditional terminals are 80 chars wide
 * Editors and viewers that do line-wrapping use the last character of
   the line to specify whether there was a wrap, otherwise you can't
   tell if the line is wrapped or there's a newline.

So a line that is exactly 80 characters long would look like this in
such a viewer:

this line...is 80 chars lon\
g
and this isn't


Hence the restriction to 79 chars to avoid that wrap.  Also, some kind
-of-broken terminals used to automatically scroll the window if you
wrote a character to the bottom-right-most character (line 24 / char
80).
-- 

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] Git for windows patch

2016-01-15 Thread Paul Smith 
On Fri, 2016-01-15 at 11:37 -0500, Jean-Christophe Fillion-Robin wrote:
> > The existence of \bin is there only for backward
> -compatibility
> 
> I guess we could also add "Git/usr/bin" to the suffixes so that it
> prefer newer version first ?
> 
> PATH_SUFFIXES Git/usr/bin Git/cmd Git/bin 

I'm not sure which command you're looking for?

git.exe exists only in Git/bin (old-style) and Git/cmd.  Where both
exist they'll have exactly the same version of git.exe in them.

I think using Git/cmd only to find git.exe is fine; I'm pretty sure
it's always existed there even in older releases of Git for Windows, an
d will continue to do so going forward.

You definitely don't need Git/usr/bin unless you want to find all the
UNIX tools.  Git.exe is not there.
-- 

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] Git for windows patch

2016-01-15 Thread Paul Smith 
On Fri, 2016-01-15 at 10:05 -0500, Shawn Waldon wrote:
> Looking at the git installation, there is another executable
> "C:\Program Files (x86)\Git\cmd\git.exe", but I have never pointed
> CMake at that one.  What is the difference between the two?  I can
> change the patch to use the other one, but I'd like to understand why
> it is necessary.

There is no difference between them.  When you install Git for Windows
the installer gives a choice of three different ways to set up %PATH%.

One way is to not add anything to %PATH%: then git is only available
from within the Git bash shell not from within command.com shell.

The second way is to make git, only (plus a few helpers like gitk,
start-ssh-agent, etc.) available on %PATH%: then git is available from
command.com but none of the other UNIX tools like find, diff, etc. are
available from command.com (only from Git shell).  In this install
method the \cmd directory is added to %PATH%.

The last way is to allow git plus all the ming32 versions of UNIX tools
that come with Git to be available to command.com.  In this install
method both \cmd AND \usr\bin are added to %PATH%.

The existence of \bin is there only for backward
-compatibility, because some people coming from older versions of Git
for Windows might be referencing it.  It shouldn't be used anymore by
modern installs (it contains bash.exe and sh.exe both of which are in
\usr\bin, and git.exe which is in \cmd).
-- 

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] Code style auto-formatting

2015-11-17 Thread Paul Smith 
On Tue, 2015-11-17 at 08:14 +, Stuermer, Michael SP/HZA-ZSEP wrote:
> In short, there is no fully automated style checking. If someone would
> come up with a tool & configuration I would love to use this. So far I
> tested astyle and the C++ edition of ReSharper (unfortunately quite
> expensive).

We've used uncrustify with excellent results in the past, FWIW.

It is a major hassle though.  We did a complete code reformat with a
well-defined process, and then had all developers apply reformatting to
their personal branches using a particular set of steps to minimize the
insanity.

-- 

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] [CMake] Forcing colorization of output from cmake

2014-10-09 Thread Paul Smith 
Thanks Brad.  I wrote a bunch more below and left it for posterity.
However thinking more about this I wonder if we couldn't make this
simpler.

What I really want is that if MAKE_TERMOUT is set to a non-empty value,
cmake should pretend that it's in a terminal regardless of what isatty()
says.  We can do this easily enough by adding a simple test to
Terminal.c:kwsysTerminalStreamIsVT100() _without_ adding any code
anywhere else:

   /* Check for a valid terminal.  */
   if(!default_vt100)
 {
 ...
 }
+
+  /* If we're being run from GNU make 4.1+ see if IT thinks we have a TTY.  */
+  const char* termout = getenv(MAKE_TERMOUT);
+  if(termout  termout[0] != '\0')
+{
+return 1;
+}

In a way this is gross, certainly, but this function already checks for
environment variable such as TERM, EMACS, etc. which are set by calling
utilities and handles them specially.  So why not MAKE_TERMOUT as well?

That one change is enough for my particular use-case, without any other
changes (don't need a FORCE setting for color).  I think it would be
useful to allow FORCE (I think this is a good capability to provide; as
I mentioned other tools that support colorization such as GCC etc. to
provide an always-type flag) but it would be decoupled from this GNU
make capability.

Thoughts?


On Thu, 2014-10-09 at 09:55 -0400, Brad King wrote:
 The Source/kwsys part of the change actually belongs in a separate
 KWSys upstream first.  I've added a modified version of your change
 for upstream review and testing here:
 
  http://review.source.kitware.com/17578
 
 Please try out that version with the rest of your changes.

OK.  I see that in your version FORCE only comes into effect if we have
a known good terminal (the new code comes after the check for valid
terminal).

Personally I would expect FORCE to be stronger than that, and return
true regardless of TERM settings.  Whether or not it should override
EMACS env.var. I don't know... I'm on the fence.  In my solution I had
it really FORCE; that is, kwsysTerminalStreamIsVT100() effectively
always was true if --switch=FORCE, regardless of EMACS or TERM.

I'm not at all familiar with Windows so I have no strong opinions on
whether FORCE should also force color output on a Windows console...
although I know a number of people who do use GNU make on Windows and
the Windows port of GNU make does set MAKE_TERMOUT properly.

  it's darn handy to have this just work without having to export
  COLOR='$(if $(MAKE_TERMOUT),FORCE)' in your ~/.bashrc or whatever.
  There's no GNU Makefiles generator, and I couldn't come up with a good
  way to implement this in the generic Unix Makefiles generator.
 
 We already have a CMAKE_COLOR_MAKEFILE option.  Perhaps instead
 of just ON or OFF values it could have a GNU value that enables
 this behavior.  When initializing it in CMakeGenericSystem.cmake
 perhaps it is possible to detect if CMAKE_MAKE_PROGRAM is a GNU
 make tool and provide a good default.

Well, it's easy enough to detect if CMAKE_MAKE_PROGRAM is GNU make, if
we can run it to test the output of ${CMAKE_MAKE_PROGRAM} --version.

The question is, what do you do in the generated makefile if you see
that it's GNU make?  Anything you'd generate into the makefile that
could choose to set --switch=FORCE would have to be GNU-specific (I
can't think of a way to write it using POSIX standard makefile syntax).
It would need to be the equivalent of:

   --switch=$(or $(COLOR),$(if $(MAKE_TERMOUT),FORCE))

to preserve the current behavior, where the COLOR variable setting can
be inherited from the environment.

What if someone runs cmake and it detects GNU make, but then they run
/my/other/make which is not GNU make?  That would work fine now but
fail if we generated GNU-specific content in 'Unix Makefiles'
generators.

If we had a different generator, like 'GNU Makefiles' for example, then
people who chose that would clearly expect the results would only work
with GNU make, but we don't have that.

-- 

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] [CMake] Forcing colorization of output from cmake

2014-10-08 Thread Paul Smith 
On Wed, 2014-10-08 at 12:55 -0400, Brad King wrote:
 On 10/08/2014 12:15 PM, Paul Smith wrote:
  Maybe we could add another valid value to --switch, like --switch=FORCE
  which would always colorize.
 [snip]
  The best option seems to be to add another flag to the color bitflag
  variable that forces colorization always.
 
 Yes, I think both of the above make sense.  If you want to work on
 it please read CONTRIBUTING.rst from the top of our source tree
 in Git ( http://cmake.org/cmake.git ) and come to the developers
 list with a proposal:

Hi all.  Attached please find a proposed patch for the above.  I still
think there's some slightly awkward redundancy between AssumeTTY and the
new ForceTTY, but I'm not sure these can actually be combined into one
flag... certainly not without reworking more of how AssumeTTY is
interpreted and used than I felt confident with.

I didn't try to allow FORCE to be case-insensitive.  It wouldn't be
hard, but I wasn't sure if it was worth it.  You must capitalize it as
the code is written today.  I found precedent for both options.

Also, the check for MAKE_TERMOUT might not be something you want to
keep... there's not a lot of precedent in the code, that I found, for
looking at other utilities' environment variables.  On the other hand
it's darn handy to have this just work without having to export
COLOR='$(if $(MAKE_TERMOUT),FORCE)' in your ~/.bashrc or whatever.
There's no GNU Makefiles generator, and I couldn't come up with a good
way to implement this in the generic Unix Makefiles generator.
From 82d2c63750c706e5f4f749a123934c725432 Mon Sep 17 00:00:00 2001
From: Paul Smith p...@mad-scientist.net
Date: Wed, 8 Oct 2014 14:18:14 -0400
Subject: [PATCH] cmake: Allow forced color output

Provide a new Terminal.h flag, Color_ForceTTY, which causes color output
always regardless of TTY/Console settings.  If --switch=FORCE is given
on the cmake command line, enable this flag.  Also check for the
MAKE_TERMOUT variable, set by GNU make 4.1+ when make is capturing
stdout which will eventually go to a terminal, and set Color_ForceTTY.
---
 Source/cmSystemTools.cxx   | 36 +---
 Source/cmcmd.cxx   |  8 +++-
 Source/kwsys/Terminal.c|  8 +---
 Source/kwsys/Terminal.h.in | 17 +++--
 4 files changed, 48 insertions(+), 21 deletions(-)

diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index fbb4416..7c983c6 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -2290,31 +2290,45 @@ std::string const cmSystemTools::GetCMakeRoot()
 void cmSystemTools::MakefileColorEcho(int color, const char* message,
   bool newline, bool enabled)
 {
+  if(!enabled)
+{
+// Color is disabled.  Print without color.
+fprintf(stdout, %s%s, message, newline? \n : );
+return;
+}
+
   // On some platforms (an MSYS prompt) cmsysTerminal may not be able
   // to determine whether the stream is displayed on a tty.  In this
   // case it assumes no unless we tell it otherwise.  Since we want
   // color messages to be displayed for users we will assume yes.
   // However, we can test for some situations when the answer is most
-  // likely no.
-  int assumeTTY = cmsysTerminal_Color_AssumeTTY;
+  // likely no, and other cases where it should be forced to yes.
+  int flags = cmsysTerminal_Color_AssumeTTY;
+
   if(cmSystemTools::GetEnv(DART_TEST_FROM_DART) ||
  cmSystemTools::GetEnv(DASHBOARD_TEST_FROM_CTEST) ||
  cmSystemTools::GetEnv(CTEST_INTERACTIVE_DEBUG_MODE))
 {
 // Avoid printing color escapes during dashboard builds.
-assumeTTY = 0;
-}
-
-  if(enabled)
-{
-cmsysTerminal_cfprintf(color | assumeTTY, stdout, %s%s,
-   message, newline? \n : );
+flags = 0;
 }
   else
 {
-// Color is disabled.  Print without color.
-fprintf(stdout, %s%s, message, newline? \n : );
+// Newer versions of GNU make (4.0+) have the ability to separate the
+// output of parallel builds so they don't interfere with each other.
+// However this means commands invoked by make don't appear to have a TTY.
+// GNU make 4.1+ exports an environment variable MAKE_TERMOUT which is
+// non-empty if make thinks that it is printing _it's_ output to stdout.
+// If this variable exists and is non-empty, then force color output.
+const char* var = cmSystemTools::GetEnv(MAKE_TERMOUT);
+if(var  var[0] != '\0')
+  {
+  flags |= cmsysTerminal_Color_ForceTTY;
+  }
 }
+
+  cmsysTerminal_cfprintf(color | flags, stdout, %s%s,
+ message, newline? \n : );
 }
 #endif
 
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index a0c67e0..af9b139 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -907,6 +907,7 @@ int cmcmd::ExecuteEchoColor(std::vectorstd::string args)
 
   bool enabled = true;
   int color = cmsysTerminal_Color_Normal;
+  int force = 0;
   bool