[cmake-developers] CMAKE_VISIBILITY_INLINES_HIDDEN incorrectly applied to non C++ sources?
I found CMAKE_VISIBILITY_INLINES_HIDDEN and wanted to replace my custom gcc flag with it. For C it causes the warning: command line option ‘-fvisibility-inlines-hidden’ is valid for C++/ObjC++ but not for C. Independent of the actual language the code currently seems to apply CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN to the compile flags. (cmLocalGenerator.cxx AddInlineVisibilityCompileOption()) Is this intended? CMAKE_LANG_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN would fix the warning for me since it would be undefined for C. Nils -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMAKE_VISIBILITY_INLINES_HIDDEN incorrectly applied to non C++ sources?
On 01/31/2014 02:27 PM, Stephen Kelly wrote:
Does a patch like
AddVisibilityCompileOption(flags, target, this, lang);
- AddInlineVisibilityCompileOption(flags, target, this);
+ if (strcmp(lang, CXX))
+{
+AddInlineVisibilityCompileOption(flags, target, this);
+}
if (strcmp(lang, CXX) == 0) should work.
help? If so, can you see about adding a unit test and merging to next?
I've got no idea how to test for this properly (yet) but I'll look into it.
Thanks!
Nils
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014725]: shared library is mistaken for an executable by is_file_executable
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14725
==
Reported By:Bastian Angermann
Assigned To:
==
Project:CMake
Issue ID: 14725
Category: CPack
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-01-31 15:10 EST
Last Modified: 2014-01-31 15:10 EST
==
Summary:shared library is mistaken for an executable by
is_file_executable
Description:
Running fixup_bundle on an executable the depends on libQtCore.so.4 will fail,
since libQtCore.so.4 is mistaken for an position independent executable by
is_file_executable. The culprit is the following test in GetPrerequisits.cmake:
if(${file_ov} MATCHES shared object.*\(uses shared libs\))
which is not specific enough.
Steps to Reproduce:
Run
file libQtCore.so.4
libQtCore.so.4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs),
BuildID[sha1]=0x46033c4f1e9e6221817fd9eb4d9ce3fdd7c40791, stripped
The output matched the pattern tested for, even though this is a shared library.
A PIE compiled on the same system yields:
gcc -fPIE test.cpp
file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.24,
BuildID[sha1]=0x7a9ef65567c34d0e38a911c4e29273df9eb34f79, not stripped
Additional Information:
The system is question is a Ubuntu 13.10, with the vendor supplied g++. The Qt
library in question is not the system Qt, it is compiled from the official Qt
4.8.5 sources.
g++ --version
g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
ld --version
GNU ld (GNU Binutils for Ubuntu) 2.23.2
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
==
Issue History
Date ModifiedUsername FieldChange
==
2014-01-31 15:10 Bastian AngermannNew Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] gcc-ipo post cmake 3.0
I created gcc-ipo to replace gcc-binutil-wrappers. It implements the INTERPROCEDURAL_OPTIMIZATION target properties for gcc following the example of the existing implementation for the intel compiler. master itself is closed for new features. I assume the same is true for next or is it open for post 3.0 development? Nils -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] AStyle or similar code beautifier
Code formatting is completely out of scope of building system. -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Mixing gcc and icc in the same library with CMake
Hi all, I am currently working on a project that is partially compiled with icc, under linux. Some of our libraries are mixing files compiled with gcc/icc, and I am wondering what is the best way to do that ? On what I saw on the internet, if you are fully using icc as compiler, the best is to change CC to icc, but in our case, we cannot full switch to icc compilation (licenses are really expensives, and we are more than 100 developpers...) As a first try, I have defined a new language in CMake (following recommandation from how to present in sources), and set properties file language to ICC for those that need it). Do you think it's a good approach to go on with this ? Do you have another recommandation ? -- Jérôme Baussé -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
On 2014-01-31 13:55+0400 Игорь Пашев wrote: Code formatting is completely out of scope of building system. I disagree with your attempt to shut off discussion. Some projects don't use code styling, others run a script aperiodically to clean up the code (PLplot uses uncrustify that way). Both of those cases are out of CMake scope, but I am also sure that some projects (like is clear with the OP) prefer code styling to be under CMake control. So my own opinion is that topic is certainly a legitimate one here. And to answer the OP's question, I can highly recommend uncrustify for code styling, but to my knowledge there is no CMake support for uncrustify (yet). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
On Fri, Jan 31, 2014 at 2:01 AM, Rob McDonald rob.a.mcdon...@gmail.com wrote: All, I'm interested in adding a code beautifier to my project. I'm looking at AStyle, but am open to others. Implementing a FindAStyle.cmake is pretty trivial. Likewise, implementing custom targets is pretty straightforward in the simple case. However, I thought there might be some canonical/idiomatic examples of this sort of thing. Any pointers to projects that do this particularly well? Are there any other code beautifiers that already have CMake support? I don't know of any canonical way of doing this - it's going to pretty similar to targets that run doxygen or otherwise trigger custom action, assuming the idea is to have make astyle-format or something similar that runs astyle on all your source files. BRL-CAD has implemented (working but not yet activated for default use) an integration of astyle that makes incorrect styling of source code files a compile-time error when building the system. It's both more elaborate and more invasive than a run astyle build target, but does compel developers to take styling rules seriously. Sort of like -Werror for code formatting. There's also the option of print noisy warnings but keep building for a less draconian approach that's still hard to ignore. Cheers, CY -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
On Fri, 2014-01-31 at 02:26 -0800, Alan W. Irwin wrote: And to answer the OP's question, I can highly recommend uncrustify for code styling I agree with Alan. We did a huge reformatting effort last year to change a very large C++ codebase from a style based loosely on Whitesmith to a more common style. I started with AStyle which is a solid program, but it has limited customization support. Then I found uncrustify and was quite satisfied with it. I sent a few patches for minor fixes and they were well received. The main issue with uncrustify is that the documentation could be better: for some of the more advanced settings it's very hard to understand exactly what they control. I had to do a bit of scripting around it since uncrustify didn't handle all the whitespace conversion we wanted, but it worked great! We didn't try to integrate it with the build system. We just checked in the configuration file and a script people could use if they wanted to re-beautify their code. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
2014-01-31 Paul Smith p...@mad-scientist.net: I had to do a bit of scripting around it since uncrustify didn't handle all the whitespace conversion we wanted, but it worked great! We didn't try to integrate it with the build system. We just checked in the configuration file and a script people could use if they wanted to re-beautify their code. Would you mind sharing the script you used with us? -- Erk - L'élection n'est pas la démocratie -- http://www.le-message.org -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
On 31/01/14 14:11, Paul Smith wrote: On Fri, 2014-01-31 at 02:26 -0800, Alan W. Irwin wrote: And to answer the OP's question, I can highly recommend uncrustify for code styling I agree with Alan. We did a huge reformatting effort last year to change a very large C++ codebase from a style based loosely on Whitesmith to a more common style. I started with AStyle which is a solid program, but it has limited customization support. Then I found uncrustify and was quite satisfied with it. I sent a few patches for minor fixes and they were well received. The main issue with uncrustify is that the documentation could be better: for some of the more advanced settings it's very hard to understand exactly what they control. That's why I like universalindentgui, a standard Ubuntu package. You can immediately see what changes will be made to the code when you fiddle with one of the many settings in uncrustify (assuming it has effect on the source file you're viewing). I had to do a bit of scripting around it since uncrustify didn't handle all the whitespace conversion we wanted, but it worked great! We didn't try to integrate it with the build system. We just checked in the configuration file and a script people could use if they wanted to re-beautify their code. attachment: loose.vcf-- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
What would be a good way to run a tool like this just before compiling? My naive solution is going to be to add a custom command to run it and touch a stamp, a target to run that custom command, and then make every single target in my project depend on that custom target. Is there a less invasive way to do this in cmake? Sent from my iPhone On Jan 31, 2014, at 9:06, Marcel Loose lo...@astron.nl wrote: On 31/01/14 14:11, Paul Smith wrote: On Fri, 2014-01-31 at 02:26 -0800, Alan W. Irwin wrote: And to answer the OP's question, I can highly recommend uncrustify for code styling I agree with Alan. We did a huge reformatting effort last year to change a very large C++ codebase from a style based loosely on Whitesmith to a more common style. I started with AStyle which is a solid program, but it has limited customization support. Then I found uncrustify and was quite satisfied with it. I sent a few patches for minor fixes and they were well received. The main issue with uncrustify is that the documentation could be better: for some of the more advanced settings it's very hard to understand exactly what they control. That's why I like universalindentgui, a standard Ubuntu package. You can immediately see what changes will be made to the code when you fiddle with one of the many settings in uncrustify (assuming it has effect on the source file you're viewing). I had to do a bit of scripting around it since uncrustify didn't handle all the whitespace conversion we wanted, but it worked great! We didn't try to integrate it with the build system. We just checked in the configuration file and a script people could use if they wanted to re-beautify their code. loose.vcf -- 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://www.cmake.org/mailman/listinfo/cmake -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
2014-01-31 Leif Walsh leif.wa...@gmail.com: What would be a good way to run a tool like this just before compiling? I'd prefer running such a tool *after* compiling. If you have a syntax error, your sources can be ruinned. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
I'll second (third) the vote for uncrustify over astyle. Astyle doesn't have enough options to take care of all style issues, with uncrustify you can configure everything. Also check out clang-format - it only supports 3 styles (last I checked), but if one of them fit it might be easiest. What works well for us is a custom script that ties into our version control, and code review tool. Since everyone is using this script to upload code reviews they get for free uncrustify run on changed files, and cppcheck (you are a fool not to use this as a minimum requirements things in my opinion) is also run on all code. This script is of course tied very closely to our development process and servers and so it isn't worth sharing. However it is easy to write something similar for your processes, and seems like a better course of action. Once a file is uncrustifed it doesn't need to be checked on everyone's build again. You just need to ensure the tool is run before the code reaches version control. On the same lines most source control systems allow you to write a pre checkin hook. While it is possible to do the work in cmake, I don't think it is the right approach. -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Paul Smith Sent: Friday, January 31, 2014 7:12 AM To: Alan W. Irwin Cc: CMake ML Subject: Re: [CMake] AStyle or similar code beautifier On Fri, 2014-01-31 at 02:26 -0800, Alan W. Irwin wrote: And to answer the OP's question, I can highly recommend uncrustify for code styling I agree with Alan. We did a huge reformatting effort last year to change a very large C++ codebase from a style based loosely on Whitesmith to a more common style. I started with AStyle which is a solid program, but it has limited customization support. Then I found uncrustify and was quite satisfied with it. I sent a few patches for minor fixes and they were well received. The main issue with uncrustify is that the documentation could be better: for some of the more advanced settings it's very hard to understand exactly what they control. I had to do a bit of scripting around it since uncrustify didn't handle all the whitespace conversion we wanted, but it worked great! We didn't try to integrate it with the build system. We just checked in the configuration file and a script people could use if they wanted to re-beautify their code. -- 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://www.cmake.org/mailman/listinfo/cmake -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
On 2014-01-31 02:01, Rob McDonald wrote: I'm interested in adding a code beautifier to my project. I'm looking at AStyle, but am open to others. Implementing a FindAStyle.cmake is pretty trivial. Likewise, implementing custom targets is pretty straightforward in the simple case. However, I thought there might be some canonical/idiomatic examples of this sort of thing. Any pointers to projects that do this particularly well? Are there any other code beautifiers that already have CMake support? By CMake support, do you mean that can beautify CMake script? Or that have an existing find module? (For a program like this I'm not sure I'd bother with a find module; often, find_program is all you really need.) As far as recommended C/C++ beautifiers, these days you might want to look at clang-format... parsing C++ is getting harder and harder with C++11 and later; as such it stands to reason that a tool that is backed by a well maintained, full-blown C++ parser is likely to be beneficial. I do use astyle for some of my own projects, but I've found that I have to do a non-trivial amount of additional pre- and post-processing to get good results. -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
Hello, I use astyle in my projects but it is not related to build (not a target). I have a cmake script that I launch using cmake -P so I don't have to write too much .bat or .sh scripts. This script has the following options (using -D command line parameters): - folder where to recursively find the sources to be beautified - whether or not to run the tool inplace or copy files to another directory first so I can do a diff between before and after Regards, Gregoire -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of ? ? Sent: vendredi 31 janvier 2014 16:54 To: Leif Walsh Cc: cmake@cmake.org Subject: Re: [CMake] AStyle or similar code beautifier 2014-01-31 Leif Walsh leif.wa...@gmail.com: What would be a good way to run a tool like this just before compiling? I'd prefer running such a tool *after* compiling. If you have a syntax error, your sources can be ruinned. -- 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://www.cmake.org/mailman/listinfo/cmake -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
Thanks to everyone for all the helpful responses. It looks like most of the ideas were pretty similar to what I was thinking. Glad to know I wasn't missing anything huge. I had found UniversalIndentGUI and plan on using it. I had also found uncrustify and will take a closer look at it. On Fri, Jan 31, 2014 at 1:55 AM, Игорь Пашев pashev.i...@gmail.com wrote: Code formatting is completely out of scope of building system. I think that CMake has historically trended towards an expansionist view of what it can/should be used for, not a restrictionist one. I think a lot of the other posters make good cases for why this may be a good idea. In general, I think of CMake as a tool that helps to standardize working with code. That can be cross platform builds, support for build farms and unit testing, automatic documentation generation, packaging of the project, etc. I want to clean up a large codebase with years of formatting neglect in an automated way. AStyle or Uncrustify are the right tool for this. I would like to give my team an easy way to check the formatting against the same style. Including a config file or the full command line with options is a good tool for this. My team works on different platforms, so a FindAStyle.cmake which just uses Find_Program and CMake's cross platform scripting are good solutions to make this easy. Including format checking or reformatting as build targets increase the probability that my team will use these tools. With CMake, those build targets show up for my team, no matter whether they use Make, Visual Studio, Eclipse, etc. If our project someday graduates to a more advanced level, then the kind of integration that BRL-CAD uses with automatic format checks with warnings on every build could be a good step -- and CMake would be a good tool to help make that happen. Rob -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Specify 64bit-specific flag
Hi all ! First of all, I apologize for my bad english ;) I'm trying to compile a fat-binaries on OSX using LuaJIT. The problem is that the doc says I have to add some flags (-pagezero_size 1 -image_base 1) with a 64bit to not get a segfault, and on the other hand, it won't compile with the 32bit build (ld: section __mach_header (address=0x1, size=21904) would make the output executable exceed available address range for architecture i386) Since I'm configuring the fat-build with the CMAKE_OSX_ARCHITECTURES=i386;x86_64 option, is there a way to specify the precedent flag with the 64bit build, and not use it with the 32bit build, or should I build these two binaries separately (or build a 32bit-only binary) ? Thanks you for reading :) -- View this message in context: http://cmake.3232098.n2.nabble.com/Specify-64bit-specific-flag-tp7586655.html Sent from the CMake mailing list archive at Nabble.com. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
On 2014-01-31 14:24+0100 Eric Noulard wrote: Would you mind sharing the script you used with us? Although that question was directed to someone else, you might be interested in scripts/style_source.sh within the PLplot source code. There are options to show diffs (or not) and apply the changes shown by those diffs or not. There is also some sed processing used so that uncrustify can style *.i files (Swig configuration files). There is an addition a further (python) script called by scripts/style_source.sh that enforces the C++ (//) style of commenting on C code (which we prefer). The scripts/style_source.sh script and the sed and python scripts it uses (in addition to uncrustify) are now reliable enough that I normally just use the --apply option. Returning back to the original topic, if someone did decide to implement full-blown CMake support for code styling, then one obvious possibility is to use properties (specified for any of directory source or target) to control styling. Here are my thoughts on the properties required based on my experience with the above script. You would need support for multiple STYLE_COMMAND properties (similar to execute_process COMMAND's) to identify the series of commands that are used (typically in a pipeline which is why I mentioned excecute_process) for styling a file. You would need properties to support what to do with the style checker results, e.g., warn or error out if style does not conform, show diffs, or apply. CMake support for Swig support would likely have to be changed to allow styling properties to apply to the *.i files. In my view it would also be essential to have some overall CMake variable (which defaults to OFF) concerning whether to use the styling properties that are specified by the build system. Most users won't have the code styling tools (e.g., a specific version of uncrustify like we use in our case) installed, and even project developers would not want to check style every time they did a build since that would noticeably add to build times. Of course, this is just a convenience variable, but in its absence each project that uses styling tools would have to implement conditional CMake code at each place where style options were used. So I classify this convenience option as essential. One advantage of integrating styling support into CMake in the way I have outlined is there would be just one tool where source code needs to be identified (i.e., CMake) rather than two (i.e., CMake and some external script). Even though finding source code is pretty straightforward with a shell script that uses file globbing, I still feel that advantage of a CMake implementation is worth having so I would likely abandon my script and move to using CMake for styling if support for such styling includes the capabilities I have mentioned above. And obviously such an implementation of CMake support for code styling would appeal even more to those interesting in styling their code but who have not yet written a script to do that. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
On Fri, 2014-01-31 at 14:24 +0100, Eric Noulard wrote: We didn't try to integrate it with the build system. We just checked in the configuration file and a script people could use if they wanted to re-beautify their code. Would you mind sharing the script you used with us? Sure, it's pretty simple. Works on Linux and Mac. Windows users have to fend for themselves :-). In addition to standard uncrustify, this converts all TABs to the appropriate number of spaces (uncrustify doesn't mess with stuff inside comments for example) and it removes all trialing whitespace. This doesn't make any backup files; it's assumed you're using a source control system and you've committed a copy beforehand (because it was written for a one-time reformat originally) but if you want to keep the .orig file for safety, just don't delete it. reformat.sh Description: application/shellscript -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] AStyle or similar code beautifier
2014-01-31 Paul Smith p...@mad-scientist.net: On Fri, 2014-01-31 at 14:24 +0100, Eric Noulard wrote: We didn't try to integrate it with the build system. We just checked in the configuration file and a script people could use if they wanted to re-beautify their code. Would you mind sharing the script you used with us? Sure, it's pretty simple. Works on Linux and Mac. Windows users have to fend for themselves :-). Thanks. Thanks to Alan as well for the similar file in PLplot. -- Erk L'élection n'est pas la démocratie -- http://www.le-message.org -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Add support for Metro apps
I've updated my patch based on comments in http://www.cmake.org/Bug/view.php?id=13511#c35015. Minmin 2014-01-31 Minmin Gong minmin.g...@gmail.com: Here comes a new version of this patch. In this version, ARM are also supported. Modifications include: 1. Determine MSVC ARM compiler. Cmake can determine and test VC's x86-arm compiler correctly, and mark it as cross compiling. This feature is inspired by Martell Malone's patch in http://www.cmake.org/Bug/view.php?id=13511#c32952. 2. Modify ARM's utility project to Win32 configuration. Utility projects, such as ALL_BUILD and ZERO_CHECKS, can't be win store or ARM configuration. They are changed to Win32 by default. With this patch, any configuration targeting WinRT platform should be supported. The project files can be generated, built and depolyed well. Minmin 2013-11-27 Minmin Gong minmin.g...@gmail.com: In our project, we need to build an Win8+ Metro app. Currently the CMake do support VS_WINRT_EXTENSIONS. However, if you want to build an exe instead of dll or lib, even with x86 or x64, it always fails because lacking of some tags in vcxproj and sln. The requirements about it in our project are: 1. The primary platform is x86 and x64. 2. Support both MSBuild and VS2012+ for building. So I made this patch for WinRT/Metro apps, based on the master branch of CMake. In this patch, 1. Add AppContainerApplication, ApplicationType, MinimumVisualStudioVersion and ApplicationTypeRevision tags to vcxproj when VS_WINRT_EXTENSIONS is on. 2. Recognize AppxManifest file type. 3. A dedicated boolean source file property VS_WINRT_CONTENT is added. Generator expressions is also supported here. 4. Add Deploy.0 in .sln for deploy WinRT apps by default, as WinCE apps do. 5. Add PackageCertificateKeyFile tag to vcxproj for package certification. After that, an app with x86 or x64 configuration can be correctly built an packed. Do you have some more suggestions about this feature? Thanks. -- Minmin Gong -- Minmin Gong -- Minmin Gong 0001-CMake-Add-support-for-WinRT-platforms-and-metro-apps.v2.patch Description: Binary data -- 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://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.12.2-7357-ga5f7a74
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via a5f7a74e3edd1dacddad9525e2de1baaacb0dce7 (commit)
via 223494653c9cccf58b7bb0275c2636d96ef89a75 (commit)
via f35c01e2a5e3834094fbd98eccfc2a686872fceb (commit)
from 02227888b572de741df035dd58f83deca21c5ff9 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a5f7a74e3edd1dacddad9525e2de1baaacb0dce7
commit a5f7a74e3edd1dacddad9525e2de1baaacb0dce7
Merge: 0222788 2234946
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Fri Jan 31 10:14:59 2014 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Jan 31 10:14:59 2014 -0500
Merge topic 'fix-visibility-inlines-hidden' into next
22349465 VisibilityInlinesHidden: only apply -fvisibility-inlines-hidden to
C++ sources
f35c01e2 CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=223494653c9cccf58b7bb0275c2636d96ef89a75
commit 223494653c9cccf58b7bb0275c2636d96ef89a75
Author: Nils Gladitz nilsglad...@gmail.com
AuthorDate: Fri Jan 31 16:09:06 2014 +0100
Commit: Nils Gladitz nilsglad...@gmail.com
CommitDate: Fri Jan 31 16:09:06 2014 +0100
VisibilityInlinesHidden: only apply -fvisibility-inlines-hidden to C++
sources
diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index c13b8ee..a2a66ae 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -2187,7 +2187,11 @@ void cmLocalGenerator
return;
}
AddVisibilityCompileOption(flags, target, this, lang);
- AddInlineVisibilityCompileOption(flags, target, this);
+
+ if(strcmp(lang, CXX) == 0)
+{
+AddInlineVisibilityCompileOption(flags, target, this);
+}
}
//
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index a79111a..17fbc59 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -400,6 +400,28 @@ if(BUILD_TESTING)
ADD_TEST_MACRO(PositionIndependentTargets PositionIndependentTargets)
endif()
+ if(CMAKE_CXX_COMPILER_ID MATCHES GNU AND
+CMAKE_SYSTEM_NAME MATCHES Linux)
+
+include(CheckCXXCompilerFlag)
+check_cxx_compiler_flag(
+ -fvisibility-inlines-hidden run_inlines_hidden_test)
+ endif()
+
+ if(run_inlines_hidden_test)
+add_test(VisibilityInlinesHidden ${CMAKE_CTEST_COMMAND}
+ --build-and-test
+ ${CMake_SOURCE_DIR}/Tests/VisibilityInlinesHidden
+ ${CMake_BINARY_DIR}/Tests/VisibilityInlinesHidden
+ ${build_generator_args}
+ --build-project VisibilityInlinesHidden
+ --build-options ${build_options}
+)
+list(APPEND TEST_BUILD_DIRS
+ ${CMake_BINARY_DIR}/Tests/VisibilityInlinesHidden
+)
+ endif()
+
add_test(LinkFlags-prepare
${CMAKE_CTEST_COMMAND} -C \${CTEST_CONFIGURATION_TYPE}
--build-and-test
diff --git a/Tests/VisibilityInlinesHidden/CMakeLists.txt
b/Tests/VisibilityInlinesHidden/CMakeLists.txt
new file mode 100644
index 000..8ebc39c
--- /dev/null
+++ b/Tests/VisibilityInlinesHidden/CMakeLists.txt
@@ -0,0 +1,14 @@
+cmake_minimum_required(VERSION 2.8)
+
+project(VisibilityInlinesHidden)
+
+add_library(inlines_hidden SHARED foo.cpp bar.c)
+set_property(TARGET inlines_hidden PROPERTY VISIBILITY_INLINES_HIDDEN ON)
+target_compile_options(inlines_hidden PRIVATE -Werror)
+
+add_custom_command(TARGET inlines_hidden POST_BUILD
+ COMMAND ${CMAKE_COMMAND}
+-DCMAKE_NM=${CMAKE_NM}
+-DTEST_LIBRARY_PATH=$TARGET_FILE:inlines_hidden
+-P ${CMAKE_CURRENT_SOURCE_DIR}/verify.cmake
+)
diff --git a/Tests/VisibilityInlinesHidden/bar.c
b/Tests/VisibilityInlinesHidden/bar.c
new file mode 100644
index 000..e425999
--- /dev/null
+++ b/Tests/VisibilityInlinesHidden/bar.c
@@ -0,0 +1 @@
+void bar() {}
diff --git a/Tests/VisibilityInlinesHidden/foo.cpp
b/Tests/VisibilityInlinesHidden/foo.cpp
new file mode 100644
index 000..2b66b69
--- /dev/null
+++ b/Tests/VisibilityInlinesHidden/foo.cpp
@@ -0,0 +1,11 @@
+class Foo
+{
+public:
+void bar() {}
+};
+
+void baz()
+{
+ Foo foo;
+ foo.bar();
+}
diff --git a/Tests/VisibilityInlinesHidden/verify.cmake
b/Tests/VisibilityInlinesHidden/verify.cmake
new file mode 100644
index 000..80dd13c
--- /dev/null
+++ b/Tests/VisibilityInlinesHidden/verify.cmake
@@ -0,0 +1,14 @@
+execute_process(COMMAND ${CMAKE_NM} -D ${TEST_LIBRARY_PATH}
+ RESULT_VARIABLE RESULT
+ OUTPUT_VARIABLE OUTPUT
+ ERROR_VARIABLE ERROR
+)
+
+if(NOT ${RESULT} STREQUAL 0)
+ message(FATAL_ERROR nm failed [${RESULT}] [${OUTPUT}] [${ERROR}])
+endif()
+
+if(${OUTPUT} MATCHES Foo[^\\n]*bar)
+
[Cmake-commits] CMake branch, master, updated. v2.8.12.2-1294-g6385c71
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 6385c7151631a4ac72490540fe75cb0b9ebbedf5 (commit) from f35c01e2a5e3834094fbd98eccfc2a686872fceb (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6385c7151631a4ac72490540fe75cb0b9ebbedf5 commit 6385c7151631a4ac72490540fe75cb0b9ebbedf5 Author: Kitware Robot kwro...@kitware.com AuthorDate: Sat Feb 1 00:01:05 2014 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Sat Feb 1 00:01:05 2014 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 27d06e4..35ef398 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 12) -set(CMake_VERSION_TWEAK 20140131) +set(CMake_VERSION_TWEAK 20140201) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
