Re: [cmake-developers] Eclipse CDT Managed build
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
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
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
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
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
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
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