Re: [cmake-developers] CMake, Ninja and Clang on windows?

[Jean-Michaël Celerier]

Hi,
to do this I currently use the following cross-compiling toolchain :
https://github.com/mstorsjo/llvm-mingw

I was able to build Qt (except webstuff since I don't use them) and a large
CMake-based project with it for instance.
Maybe it can be useful ?

Best,

---
Jean-Michaël Celerier
http://www.jcelerier.name


On Tue, Nov 6, 2018 at 11:57 AM Tobias Hunger 
wrote:

> Hi CMake Developers,
>
> we are currently trying to support Clang (without the -cl;-) on
> Windows. This fails since CMake adds extra compiler flags to the
> command line which are not in the expected format.
>
> Stackoverflow[1] suggests to set CMAKE_SYSTEM_NAME to "Generic" to
> stop that from happening.
>
> The blog post[2] referenced by StackOverflow suggests setting
> CMAKE_C_FLAGS and CMAKE_CXX_FLAGS to TRUE.
>
> Both approaches seem like big hammers to me. Are there better ways to
> get this going that will have less potential side effects?
>
> Best Regards,
> Tobias
>
> [1]:
> https://stackoverflow.com/questions/46553436/building-with-cmake-ninja-and-clang-on-windows#46593308
> [2]:
> https://metricpanda.com/rival-fortress-update-27-compiling-with-clang-on-windows
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake-developers
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] kwsysProcess threadsafety

[Jean-Michaël Celerier]

> 3) Abandon the idea to parallelize AUTOMOC/UIC

please no ! moc is a huge bottleneck in my builds (to the point that using
verdigris <https://github.com/woboq/verdigris> instead ends up having
faster build time overall).

Best,
Jean-Michaël



-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Fri, Jan 5, 2018 at 8:34 PM, Sebastian Holtermann <sebl...@xwmw.org>
wrote:

> Hello!
>
> As you might have noticed I tried to parallelize AUTOMOC/UIC.
> https://gitlab.kitware.com/cmake/cmake/merge_requests/1632
> The issue that's blocking it now is that the kwsysProcess framework
> isn't thread safe. As a consequence it is not possible for threads to
> start processes concurrently using the kwsysProcess framework.
>
> There are three options I see
>
> 1) Make kwsysProcess thread safe
>
> I don't think it's impossible but it's not a small task.
> Looking through the code I found a few issues that
> would block the whole idea for me.
>   - OpenVMS: I have little to no knowledge about OpenVMS.
> Wikipedia says it is basically abandoned.
> Can the OpenVMS code be removed? I couldn't test it anyway.
>
>   - C vs. C++
> There's a lot of C in processUNIX.c (list allocation etc.).
> I would prefer to use C++11 (or higher), especially
> std::array, std::vector, std::thread,  std::mutex, etc..
> Is C++11 acceptable in kwsysProcess?
> This would make processUNIX.c processUNIX.cpp?
>
> 2) Use libuv instead
>
> Using the libuv event loop is overkill and would probably imply that
> more threads are started than necessary
> (the libuv thread pool will be started anyway).
> But it would allow to start multiple concurrent  (moc/uic) processes.
> Is there a reason to not use libuv?
>
> 3) Abandon the idea to parallelize AUTOMOC/UIC
>
> Well, I liked the idea.
>
>
> Any thoughts?
>
> -Sebastian
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake-developers
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Native Compilers

[Jean-Michaël Celerier]

> This compilers are alredy intalled with cmake or it needs to install
separetely?

You need to install them separately.

> Another question, when you specify a for example kdevelop files is it
necessary to run at kdevelop to get the executables files?

Yes. The pipeline is like this :


* Give a description of your project in CMakeLists.txt.
* CMake generates a project file for your IDE / environment of choice (this
is because you would have different environments on Mac and Windows for
instance) from CMakeLists.txt.
* Use your IDE / environment to build your software.

Though cmake has the

cmake --build .

command that you can use, which tries to call your environment's build
function.


Best

---
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, Sep 25, 2017 at 8:39 PM, Ivam Pretti <ivamprett...@gmail.com> wrote:

> When you use cmake-gui, below the button configure  there is an option to
> choose the compiler. This compilers are alredy intalled with cmake or it
> needs to install separetely?
>
> Another question, when you specify a for example kdevelop files is it
> necessary to run at kdevelop to get the executables files?
>
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

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] Debugging find_package() search behavior?

[Jean-Michaël Celerier]

> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH.

Not always, some people sometimes feel like doing it by hand from scratch
with if(EXISTS ...). Sadly.



On Tue, Aug 29, 2017 at 5:49 PM, Brad King  wrote:

> On 08/29/2017 11:33 AM, David Cole wrote:
> > That's correct:
> >
> > find modules do what they want, and most do not pay attention to
> > CMAKE_PREFIX_PATH.
>
> CMAKE_PREFIX_PATH *is* used by find modules.
>
> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH.
> See the documentation of find_library, find_path, etc. for details.
> Each command searches an appropriate `/` where ``
> is based on the kind of command doing the searching.
>
> -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
>
-- 

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] C++11 all features available?

[Jean-Michaël Celerier]

> Thread support would be nice because Autogen could be parallelized
perfectly.

oh please yes. moc generation is almost 10% of my build time.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, Aug 21, 2017 at 4:32 PM, Sebastian Holtermann <sebl...@xwmw.org>
wrote:

> Am Montag, 21. August 2017, 10:04:28 CEST schrieben Sie:
> > On 08/21/2017 09:53 AM, Sebastian Holtermann wrote:
> > > it looks like C++11 is now a requirement for CMake itself.
> >
> > Yes.  We just merged this:
> >
> >   https://gitlab.kitware.com/cmake/cmake/merge_requests/1132
> >
> > but you beat us to the announcement.
>
> I saw the MR last week and was delighted. The iterator type naming in `for`
> loops drove me mad.
>
> > > But does this mean *all* the nice features from the std library can be
> > > used?
> > Not all.  We're still limited by some of the older C++11 compilers.
> > We'll have to see how things go on nightly builds.  As limitations
> > are found they can be documented in `Help/dev/source.rst`.
> >
> > We will require std::unique_ptr at least.
> >
> > >  - std::array
> >
> > I think so but haven't tried it.
> >
> > >  - std::basic_regex (and friends)
> >
> > We still support GCC 4.8.  IIRC its standard library doesn't have
> > the implementations in place.
>
> That's a pitty, because cmsys::RegularExpression isn't thread safe.
> Although it might be possible to make it so in a reasonable amount of time
>
> > >  - std::thread (and friends)
> >
> > No, at least not yet.  For now we're using libuv's thread primitives
> > instead.  Either way anything that needs to build during bootstrap
> > may not be able to use this.
> >
> > >  - std::atomic_flag
>
> Thread support would be nice because Autogen could be parallelized
> perfectly.
> Only it would require several utility methods to be thread safe as well.
> Many
> likely aren't though. I'll have a look at libuv.
>
> -Sebastian
>
>
> --
>
> 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
>
-- 

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] C++ IDE

[Jean-Michaël Celerier]

> Visual Studio 2017 has the best C/C++ experience with CMake

IMHO, Visual Studio's CMake integration is a joke in comparison to
QtCreator and CLion.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Fri, Aug 18, 2017 at 12:04 PM, Nagy-Egri Máté Ferenc via
cmake-developers <cmake-developers@cmake.org> wrote:

> Impressed with VSCode?? If I saw this post anywhere else than the CMake
> mailing list, I’d understand, but VSCode with CMake is horrible. The fact
> that in 2017 I have to set include directories, compiler definitions and
> target paths manually to have proper IntelliSense (Code navigation and
> syntax higlight) is absurd.
>
>
>
> As far as I saw Visual Studio 2017 has the best C/C++ experience with
> CMake. (Google: Visual Studio Open Folder support with CMake)
>
>
>
> *Feladó: *Wesley Smith <wesley.h...@gmail.com>
> *Elküldve: *2017. augusztus 10., csütörtök 6:38
> *Címzett: *Ivam Pretti <ivamprett...@gmail.com>
> *Másolatot kap: *cmake-developers@cmake.org
> *Tárgy: *Re: [cmake-developers] C++ IDE
>
>
>
> I have been really impressed with VSCode <https://code.visualstudio.com/>.
>
>
>
>
> On Sun, Aug 6, 2017 at 1:52 PM, Ivam Pretti <ivamprett...@gmail.com>
> wrote:
>
> Can you recomend an IDE to code in C/C++?
>
>
> --
>
> 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
>
>
>
>
>
> --
>
> 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
>
-- 

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] Future of ccmake and cmake-gui

[Jean-Michaël Celerier]

> For example, I've seen way too many
projects screw up with Brew because they fail to ship a binary that
can work on a clean user system who is not going to install Brew.

I must be lucky then, because just using macdeployqt copies all the
dependencies for me and
updates all the install paths correctly whether I use Qt's own build or
brew's.

> It pulls a new version of gcc instead of using Xcode/clang on
your system and builds an entire dependency chain based on GNU tools.

this is false. brew uses xcode & clang on your system.

> Similar problem for Windows...Visual Studio is the requirement.

I don't know if you are talking about Chocolatey or Qt but neither require
Visual Studio on windows.
Qt even comes with MinGW if you wish.

> And Mac doesn't have configure/autotools by defaul.

but... "configure" has nothing to do with autotools.
It's just a shell script (which is sometimes generated *from* autotools;
this is not the case with Qt AFAIK).

> and I never figured why Qt's RAM consumption footprint is so high...based
on all the DLL binary code it
has to load, or something more intrinsic to its implementation.

science can help us here :p two tools are very nice for this :

* bloaty mcbloatface for binary bloat

for file in /usr/lib/libQt5*.so ; do (echo $file; bloaty $file| grep
-A3 'text') ; done

tells us stuff like

/usr/lib/libQt5Core.so
  55.4%  2.75Mi .text  2.75Mi  55.5%
  23.5%  1.16Mi .rodata1.16Mi  23.5%
   7.3%   372Ki .eh_frame   372Ki   7.4%
   4.1%   210Ki .dynstr 210Ki   4.2%
/usr/lib/libQt5Gui.so
  70.0%  3.82Mi .text   3.82Mi  70.2%
   7.8%   438Ki .eh_frame438Ki   7.9%
   6.1%   342Ki .dynstr  342Ki   6.1%
   5.1%   286Ki .rodata  286Ki   5.1%

A bit surprising to see .eh_frame; I thought Qt was compiled with
-fno-exceptions but maybe that's just my distro.
Quite a bunch of .rodata in Qt5Core too, I wonder why.
Further examination through
readelf -x .rodata /usr/lib/libQt5Core.so | less
seems to show up a lot of locale-specific calendar text & such, e.g. names
of the months in twenty languages, currencies, time zones, etc

* And then, runtime examination: for this I tried making a minimal gui
program:
#include 
#include 
int main(int argc, char**argv)
{
  QApplication app(argc, argv);
  QMainWindow w;
  w.show();
  return app.exec();
}

compiled with
g++ -DQT_NO_DEBUG -fPIC -I/usr/include/qt/ -I/usr/include/qt/QtCore
-I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui main.cpp -lQt5Core
-lQt5Widgets

and then use the wonderful Heaptrack (https://github.com/KDE/heaptrack) :

heaptrack ./a.out

which then greets us with http://imgur.com/a/eYjaL

As you can see, "peak heap memory consumption" is at a bit less than 400
*kilobytes*. So the Qt memory usage that you see is clearly due only to
binary bloat.
And indeed (sorry for shitty bash skills):

$ ldd a.out | cut -d '=' -f1 | awk '{print "/usr/lib/" $1;}'  | xargs
readlink |  awk '{print "/usr/lib/" $1;}'  | xargs du -csh  | sort -h
16K/usr/lib/libdl-2.25.so
16K/usr/lib/libXau.so.6.0.0
24K/usr/lib/libXdmcp.so.6.0.0
32K/usr/lib/librt-2.25.so
64K/usr/lib/libdouble-conversion.so.1.0.0
68K/usr/lib/libbz2.so.1.0.6
72K/usr/lib/libGLX.so.0.0.0
72K/usr/lib/libXext.so.6.4.0
80K/usr/lib/liblz4.so.1.7.5
84K/usr/lib/libgpg-error.so.0.22.0
92K/usr/lib/libz.so.1.2.11
144K/usr/lib/libpthread-2.25.so
152K/usr/lib/liblzma.so.5.2.3
164K/usr/lib/libxcb.so.1.1.0
176K/usr/lib/libgraphite2.so.3.0.1
216K/usr/lib/libpng16.so.16.31.0
444K/usr/lib/libpcre2-16.so.0.5.0
460K/usr/lib/libpcre.so.1.2.9
536K/usr/lib/libsystemd.so.0.19.0
548K/usr/lib/libharfbuzz.so.0.10400.5
552K/usr/lib/libGL.so.1.0.0
600K/usr/lib/libGLdispatch.so.0.0.0
796K/usr/lib/libfreetype.so.6.14.0
1,1M/usr/lib/libglib-2.0.so.0.5200.3
1,1M/usr/lib/libm-2.25.so
1,2M/usr/lib/libgcrypt.so.20.2.0
1,3M/usr/lib/libX11.so.6.3.0
1,7M/usr/lib/libicuuc.so.59.1
1,9M/usr/lib/libc-2.25.so
2,5M/usr/lib/libicui18n.so.59.1
5,0M/usr/lib/libQt5Core.so.5.9.1
5,5M/usr/lib/libQt5Gui.so.5.9.1
6,4M/usr/lib/libQt5Widgets.so.5.9.1
12M/usr/lib/libstdc++.so.6.0.24
26M/usr/lib/libicudata.so.59.1
69Mtotal

So there's 17 megabytes of Qt in here; hopefully the rest would already be
loaded by your system.

Best,
Jean-Michaël

On Thu, Aug 17, 2017 at 3:34 AM, Eric Wing <ewmail...@gmail.com> wrote:

> On 8/16/17, Jean-Michaël Celerier <jeanmichael.celer...@gmail.com> wrote:
> > @Eric Wing
> >> I am not making a strong push for this, but I want to bring it up to
> > at least get people thinking about this... I am disturbed by the size
> > and complexity of Qt. My past experiences have not been good and I
> > find it a massive chore to get an environment setup (especially on Mac
> > and Win

Re: [cmake-developers] C++ IDE

[Jean-Michaël Celerier]

QtCreator is nice.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sun, Aug 6, 2017 at 10:57 PM, Rolf Eike Beer <e...@sf-mail.de> wrote:

> Am Sonntag, 6. August 2017, 17:52:13 schrieb Ivam Pretti:
> > Can you recomend an IDE to code in C/C++?
>
> KDevelop.
> --
>
> 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
>
-- 

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] Module macros/function names with single leading underscore

[Jean-Michaël Celerier]

> It's probably going to be an uncommon situation

https://www.google.fr/search?q="macro(_"+site%3A%3Ahttps%3A%2F%2Fgithub.com

A lot are namespaced but skimming a bit through the result, there is also
stuff like *_*INTERNAL_PARSE_FLAGS_ARGS, *_*fixup_target, *_*LSB_RELEASE,
*_*plugin_target_name
which may be at risk for the problem you're exposing.


Best,

---
Jean-Michaël Celerier
http://www.jcelerier.name

On Tue, Aug 1, 2017 at 10:42 PM, Brad King <brad.k...@kitware.com> wrote:

> On 07/23/2017 10:20 AM, Craig Scott wrote:
> > maybe it's worth considering renaming these single underscore
> > internal macros and functions?
>
> Projects that rely on the undocumented feature depend on being
> able to call the original function by prepending the single
> underscore.  We can't change the renaming convention without
> breaking them.  Even a policy for this may be tricky due to
> function definitions being visible globally and therefore
> skipping across policy scopes.
>
> The infinite recursion case you mentioned has long been known
> and may have a few issue tracker entries.  We haven't really
> dealt with it because the feature is undocumented and meant
> for debugging.  If anyone can come up with a compatible fix
> (e.g. explicit diagnostic) that would be great.
>
> Side note: One day I'd like to see a policy that changes
> function/macro definition scopes to be directory-based.
> I haven't thought about the correctness or side-effects of
> that in detail though.
>
> -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
>
-- 

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] ;-list in docs

[Jean-Michaël Celerier]

On Sat, May 13, 2017 at 5:39 AM, Craig Scott 
wrote:

> ;-list


It's a shorthand for semicolon-separated list :
https://cmake.org/cmake/help/v3.8/command/separate_arguments.html?highlight=semicolon
-- 

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] Splitting CMakeLib

[Jean-Michaël Celerier]

On Wed, May 10, 2017 at 4:56 PM, Egor Pugin  wrote:

> but CMakeLib looks too fat.



In this age of link-time whole-program optimizations is this really a
problem ?
-- 

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] Support for version suffixes

[Jean-Michaël Celerier]

I remember asking for the same thing a few weeks ago on IRC because of a
small behaviour change in cmake 3.8.0 rc2 that I wanted to put behind an
if(version_less).

Alphanumeric ordering would certainly work for most projects : alpha < beta
< rc. (I generally use a0, a1, a2... b0, b1, b2...)

Best
Jean-Michaël

On Mon, Mar 27, 2017 at 11:03 PM, Roger Leigh  wrote:

> Hi folks,
>
> I'd like to bring this issue to your attention to canvas some feedback
> regarding the use of version suffixes:
>
>   https://gitlab.kitware.com/cmake/cmake/issues/16716
>
> This is basically a proposal to allow an optional version suffix like
> "-rc3", "-beta1" etc. in addition to the existing major.minor.patch.tweak
> pattern, for better interoperability with systems and software releases
> already using such suffixes, and also to permit the use of such suffixes by
> CMake projects for their own purposes.  A version suffix would be usable
> anywhere currently using 4 digit versions, with all the necessary
> functionality in CMake being updated to handle this.
>
> The proposal linked above contains a much more detailed rationale and
> suggested implementation strategy.  I'd be very happy to hear any thoughts
> anyone has regarding this either on the above issue, or here.
>
>
> Thanks all,
> Roger
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

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] [Discussion] Add python support for CMakeLists

[Jean-Michaël Celerier]

(My simple user opinion):

I'm not a fan of the idea.
Not particularly because of Python, but because with this, now
if I want to use a library that someone made with a CMakeLists.py in my
project
(for instance as a submodule) :
* I also have to install Python on the machines where the build happens,
* tell my users to install Python,
* add it to their PATH...

Many already have trouble just installing and running CMake, and this adds
another
potential layer of complexity, and a fragmentation of the ecosystem.
Unless CMake would ship with its own Python interpreter ?

I know, this is a non-problem on Linux and OS X (or is it ? On my machine
/usr/bin/python is python 3 but on others it is python 2),
but there are some poor people out there stuck with Windows machines, and I
wouldn't like their lives to be even harder.

Best regards
Jean-Michaël

On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H,  wrote:

> Hello,
>
> First of all, I have been using CMake for a few years now, it is awesome
> tool, thank you.
>
> The only problem I currently have with CMake is its language, which has
> not really intended to be one. After reading a few endless discussions
> about this topic, I decided to give it a try and do something practical.
>
> My current design is using Python as an extension for the regular
> CMakeLists.txt files: if there is a CMakeLists.py file, it would be loaded.
>
> It should not be too hard to maintain, the current API design uses only
> 1-3 function that should be implemented in cmake.
>
> For more information, see the [closed] merge request #389
> .
>
> I would be happy to hear your opinion about this idea.
>
> Best regards,
> Shmuel H.
>
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

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] Current deficiencies of automoc

[Jean-Michaël Celerier]

On Fri, Oct 21, 2016 at 10:10 AM, Sebastian Holtermann 
wrote:

>
> A quick fix for the example would be to explicitly add the
> headers-to-moc to the sources list.


This has the nice side-effect of making your project much easier to use in
IDEs.
-- 

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] Dependency mechanism of CMake

[Jean-Michaël Celerier]

Hi,

Did you read this page ? The "Build Specification & Usage Requirements"
section clearly explains how it works imho.

https://cmake.org/cmake/help/v3.6/manual/cmake-buildsystem.7.html
and
https://cmake.org/cmake/help/v3.6/manual/cmake-buildsystem.7.html#build-specification-and-usage-requirements

Best
Jean-Michaël

On Thu, Aug 18, 2016 at 10:11 AM, Costean Adrian via cmake-developers <
cmake-developers@cmake.org> wrote:

> Hello CMake developers,
> I've been trying to figure out how CMake works ( so far no chance, the
> documentation of "behind the scenes of CMake" is kind of limited).
> I am interested in how CMake calculates the dependencies, if it does it
> efficient and correct.
> Could anyone brief me with a quick overview?
> Thanks and regards,
> Adrian C.
> --
>
> 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
>
-- 

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] RFC: CMake precompiled header support and custom compiler based implementation

[Jean-Michaël Celerier]

Hi,

could you give a try to the branch ?
:)

Jean-Michaël Celerier

On Sat, Dec 5, 2015 at 1:39 PM, David Cole via cmake-developers <
cmake-developers@cmake.org> wrote:

> Yes, that looks like it should work. I'll pull your branch and give it a
> try sometime in the coming week.
>
> Thanks,
> David
>
> On Friday, December 4, 2015, Daniel Pfeifer <dan...@pfeifer-mail.de>
> wrote:
>
>> On Fri, Dec 4, 2015 at 11:32 PM, David Cole <dlrd...@aol.com> wrote:
>> > Makes sense.
>> >
>> > Can I inject my own "#include " into
>> > the generated stream, or otherwise inject something into it?
>>
>> You should be able to do:
>>
>> target_include_directories(your_target
>>   PUBLIC public
>>   PRIVATE private
>>   )
>> target_precompile_headers(your_target
>>   PUBLIC
>> public_header1.h
>> public_header2.h
>>   PRIVATE
>> private_header1.h
>> private_header2.h
>>   )
>>
>> Does that answer your question? Do you think this could solve your
>> use-case?
>>
>> > Specifically, for me, I want to include some, but not ALL VTK headers
>> > for a VTK-based project.
>>
>> I don't see a problem for that.
>>
>> > Thanks for working on this.
>>
>> You are welcome. :-)
>>
>> > Let me know if you want me to be a Visual Studio tester for you.
>>
>> Yes, please. My main working environment is Linux. I appreciate any
>> feedback from different platforms.
>>
>
> --
>
> 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
>
-- 

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] C# support ready for review

[Jean-Michaël Celerier]

Simple question : do you think that this would be useable in order to
have a single build pipeline based on CMake for a Unity3D project that
also requires some native C++ libs ?

Thanks !


On Mon, Mar 21, 2016 at 8:09 AM, Stuermer, Michael  SP/HZA-ZSEP
 wrote:
> Sorry for asking, but do you mean
>
> 1. without support for ninja/nmake/make there is no use having C# support in 
> cmake
>
> or
>
> 2. using the current approach this could also work with the other generators 
> without too much additional work
>
> ?
>
> I'm just a little confused and try to find out what's on my todo list until 
> C# support may reach a mature level.
>
> best regards,
> Michael
>
>> -Original Message-
>> From: David Cole [mailto:dlrd...@aol.com]
>> Sent: Tuesday, March 08, 2016 12:51 AM
>> To: Brad King
>> Cc: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
>> Subject: Re: [cmake-developers] C# support ready for review
>>
>> Seems to me like C# support should work just fine with other generators:
>> ninja, nmake, and UNIX Makefiles included. Especially with mono on
>> Linux/Mac.
>>
>>
>> David
>>
>> > On Mar 7, 2016, at 2:12 PM, Brad King  wrote:
>> >
>> >> On 02/25/2016 05:51 AM, Stuermer, Michael  SP/HZA-ZSEP wrote:
>> >> The part that probably needs most additional work is all the C#
>> >> detection and configuration part in the module scripts.
>> >
>> > In your branch Modules/CMakeDetermineCSharpCompiler.cmake
>> currently
>> > has a lot of logic and environment checks for this.  It shouldn't need
>> > to be that complicated.  Anything requiring deep introspection of the
>> > system (especially the registry) should be something done in the C++
>> > generator implementation and provided to CMake platform files as a
>> > variable.
>> >
>> > For example, the VS generators always provide msbuild:
>> >
>> >
>> https://cmake.org/cmake/help/v3.5/variable/CMAKE_VS_MSBUILD_COMM
>> AND.ht
>> > ml
>> >
>> > For the path to the compiler tool, take a look at
>> >
>> > Modules/CompilerId/VS-10.vcxproj.in
>> >
>> > and use of it by Modules/CMakeDetermineCompilerId.cmake.  That all
>> > runs while detecting the compiler id using a small test project.
>> > It has a custom command that searches the PATH in the IDE project
>> > build environment to print out the path to the compiler.  You should
>> > create one like this for CSharp too.
>> >
>> > We'll also need to define behavior when CSharp is enabled by projects
>> > under a non-VS generator.  Other generators should reject any such
>> > attempt with an error message.
>> >
>> > Thanks,
>> > -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
> --
>
> 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
-- 

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] [Qt-creator] CMake daemon for user tools

[Jean-Michaël Celerier]

There is also https://www.cevelop.com/ which is an Eclipse derivative, they
may be interested ?

Best,

Jean-Michaël
www.i-score.org

On Fri, Feb 19, 2016 at 11:36 AM, Stephen Kelly  wrote:

> Alexander Neundorf wrote:
>
> > On Wednesday, February 17, 2016 22:59:36 Stephen Kelly wrote:
> >> On 02/15/2016 07:24 PM, Tobias Hunger wrote:
> >> > Hi Dominik,
> >> >
> >> > Am 15.02.2016 19:01 schrieb "Dominik Haumann"
> >> >  >> >
> >> > >:
> >> > > 1. Wouldn't it make sense you have a developer sprint ASAP for this?
> >> >
> >> > I'd be in, but I do not have the time to organize one. I could
> >> > probably get a room in our office though (in Berlin).
> >>
> >> I'd be up for a sprint in Berlin too, but given the muted response so
> >> far here, it's not clear who would want to join and what we could
> >> achieve.
> >
> > just out of curiosity, did you get any feedback from anybody from
> > Eclipse/CDT ?
>
> Nope. No response from there at all despite reaching out to them.
>
> > Or CodeBlocks maybe ?
>
> I didn't reach out to them, so no.
>
> 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
>
-- 

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 alternative language

[Jean-Michaël Celerier]

Throw in a


> list(GET MyList ${i} ElementA)
> list(GET MyOtherListOfSameSizeThanMyList ${i} ElementB)
> foobazify(${ElementA} ${ElementB})

(I did not want to put a ginormous code snippet, just to outline the amount
of code necessary to do simple things)

On Fri, Jan 15, 2016 at 1:28 AM, J Decker <d3c...@gmail.com> wrote:

> On Thu, Jan 14, 2016 at 3:09 PM, Jean-Michaël Celerier
> <jeanmichael.celer...@gmail.com> wrote:
> > The problem is doing :
> >
> > list(LENGTH MyList NumList)
> > math(EXPR MaxItList ${NumList}-1)
> >
> > foreach(i RANGE ${MaxItList})
> > list(GET MyOtherListOfSameSizeThanMyList ${i} Element)
> > foobazify(${Element})
> > endforeach()
> >
> Probably a bad exmple, since you're not using MyList or i that simplifies
> to
>
> foreach( Element ${MyOtherListOfSameSizeThanMylist} )
> foobazify( ${Element} )
> endforeach()
>
> > instead of :
> >
> > for i in range(0, MyList.size):
> > foobazifiy(MyOtherListOfSameSizeThanMyList[i])
> >
> >
> >
> >
> >
> > On Thu, Jan 14, 2016 at 2:08 PM, Charles Huet <charles.h...@gmail.com>
> > wrote:
> >>
> >> As long as CMake embeds everything that is required, I don't see the
> >> additional pain (since this is what it already does with the CMake
> >> language).
> >>
> >>
> >> Le jeu. 14 janv. 2016 à 13:35, Jean-Michaël Celerier
> >> <jeanmichael.celer...@gmail.com> a écrit :
> >>>
> >>>
> >>> On Wed, Jan 13, 2016 at 10:21 PM, Alexander Neundorf <neund...@kde.org
> >
> >>> wrote:
> >>>>
> >>>>
> >>>> My personal opinion: if the full power of python would be available,
> the
> >>>> build
> >>>> scripts would quickly turn into real programs, because programmers
> would
> >>>> be
> >>>> tempted to do so if all of python would be available. Then developers
> >>>> would
> >>>> have to understand two programs: the program itself, and the "build
> >>>> program".
> >>>
> >>>
> >>> The problem is when you have to do a real program for your build system
> >>> anyways (which occurs one day or another for any large enough project I
> >>> guess).
> >>> Currently it's a real pain (but it'd be even more painful to have to
> ship
> >>> Python / Bash / $script_language as part of your build 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://public.kitware.com/mailman/listinfo/cmake-developers
> >
> >
> >
> > --
> >
> > 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
>
-- 

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 alternative language

[Jean-Michaël Celerier]

On Wed, Jan 13, 2016 at 10:21 PM, Alexander Neundorf 
wrote:

>
> My personal opinion: if the full power of python would be available, the
> build
> scripts would quickly turn into real programs, because programmers would be
> tempted to do so if all of python would be available. Then developers would
> have to understand two programs: the program itself, and the "build
> program".


The problem is when you have to do a real program for your build system
anyways (which occurs one day or another for any large enough project I
guess).
Currently it's a real pain (but it'd be even more painful to have to ship
Python / Bash / $script_language as part of your build 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://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language

[Jean-Michaël Celerier]

The problem is doing :

list(LENGTH MyList NumList)
math(EXPR MaxItList ${NumList}-1)

foreach(i RANGE ${MaxItList})
list(GET MyOtherListOfSameSizeThanMyList ${i} Element)
foobazify(${Element})
endforeach()

instead of :

for i in range(0, MyList.size):
foobazifiy(MyOtherListOfSameSizeThanMyList[i])




On Thu, Jan 14, 2016 at 2:08 PM, Charles Huet <charles.h...@gmail.com>
wrote:

> As long as CMake embeds everything that is required, I don't see the
> additional pain (since this is what it already does with the CMake
> language).
>
>
> Le jeu. 14 janv. 2016 à 13:35, Jean-Michaël Celerier <
> jeanmichael.celer...@gmail.com> a écrit :
>
>>
>> On Wed, Jan 13, 2016 at 10:21 PM, Alexander Neundorf <neund...@kde.org>
>> wrote:
>>
>>>
>>> My personal opinion: if the full power of python would be available, the
>>> build
>>> scripts would quickly turn into real programs, because programmers would
>>> be
>>> tempted to do so if all of python would be available. Then developers
>>> would
>>> have to understand two programs: the program itself, and the "build
>>> program".
>>
>>
>> The problem is when you have to do a real program for your build system
>> anyways (which occurs one day or another for any large enough project I
>> guess).
>> Currently it's a real pain (but it'd be even more painful to have to ship
>> Python / Bash / $script_language as part of your build 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://public.kitware.com/mailman/listinfo/cmake-developers
>
>
-- 

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] [ANNOUNCE] CMake 3.4.0 Released

[Jean-Michaël Celerier]

> * The "CPackDeb" module now correctly excludes symlinks during
  package checksum calculation.

> * The "CPackDeb" no longer uses fakeroot and system tar program for
  packaging.

Does this mean that the ubuntu package manager will stop complaining of
CPack DEBs ?

Thanks for the great work :)

Jean-Michaël


On Thu, Nov 12, 2015 at 9:47 PM, Konstantin Podsvirov <
konstan...@podsvirov.pro> wrote:

> 12.11.2015, 21:57, "Robert Maynard" :
> > I am proud to announce that CMake 3.4.0 is now available for download at:
> > https://cmake.org/download/
> >
> > Documentation is available at:
> > https://cmake.org/cmake/help/v3.4
> >
> > Release notes appear below and are also published at
> > https://cmake.org/cmake/help/v3.4/release/3.4.html
>
> Good job! Thank you!
>
> I could not miss this event. This is a good occasion to remind about
> the existence of CPack "IFW" generator :-)
>
> https://cmake.org/cmake/help/v3.4/module/CPackIFW.html
>
> Here is a fresh not official offline installers for CMake 3.4.0 on Windows:
>
> http://ifw.podsvirov.pro/cmake/files/v3.4/cmake-3.4.0-win32-x86.exe
>
> and
>
> http://ifw.podsvirov.pro/cmake/files/v3.4/cmake-3.4.0-win64-x64.exe
>
> But I want to assure you that they are honestly built me personally of the
> official code of branch 'release' recently :-)
>
> I'll be glad if somebody test these installers for themselves and to share
> their comments and suggestions.
>
> Good luck to everyone!
>
> --
> Regards,
> Konstantin Podsvirov
> --
>
> 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
>
-- 

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] [PATCH] Macro generation for relaxed constexpr

[Jean-Michaël Celerier]

 Qt 5 provides a macro for this context which expands to either 'const' or
'constexpr' depending on whether cxx_constexpr is available, and another
macro which expands to either 'const' or 'constexpr' depending on whether
cxx_relaxed_constexpr is available.

Thinking of it, since C++14 constexpr does not imply const anymore, so
isn't this macro ambiguous wrt standard c++ ?



On Wed, Jul 8, 2015 at 10:42 PM, Stephen Kelly steve...@gmail.com wrote:

 Jean-Michaël Celerier wrote:

  I think there should be a test for the different allowed contexts of the
  ${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could
  you extend Tests/Module/WriteCompilerDetectionHeader with a test for
 that?
 
  For sure, I'll do this asap.
 

 Great, 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

-- 

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] [PATCH] Macro generation for relaxed constexpr

[Jean-Michaël Celerier]

I'm referring to the const used after methods (struct { int f() const; }).

Here is an example : https://ideone.com/C28SMn

Best regards :)




On Mon, Aug 3, 2015 at 7:20 PM, Stephen Kelly steve...@gmail.com wrote:

 Jean-Michaël Celerier wrote:

  Qt 5 provides a macro for this context which expands to either 'const'
 or
  'constexpr' depending on whether cxx_constexpr is available, and another
  macro which expands to either 'const' or 'constexpr' depending on whether
  cxx_relaxed_constexpr is available.
 
  Thinking of it, since C++14 constexpr does not imply const anymore, so
  isn't this macro ambiguous wrt standard c++ ?
 

 The 'const' keyword can be used in multiple contexts. Can you clarify which
 you mean with a reference to some document?

 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

-- 

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

[cmake-developers] [PATCH] Macro generation for relaxed constexpr

[Jean-Michaël Celerier]

Hello,

At the ned of this mail is a patch that adds generation of a macro for
the relaxed (c++14) constexpr in WriteCompilerDetectionHeader.

This is intended for compilers that support c++11 constexpr (with
everything on a single return statement) like GCC-4.9 and the upcoming
MSVC, but not extended constexpr which allows for more complete
functions. This way, code bases can reap the benefits of most recent
compilers at no cost.

Best regards
Jean-Michaël Celerier


diff --git a/Modules/WriteCompilerDetectionHeader.cmake
b/Modules/WriteCompilerDetectionHeader.cmake
index a3b73bb..f7af7ec 100644
--- a/Modules/WriteCompilerDetectionHeader.cmake
+++ b/Modules/WriteCompilerDetectionHeader.cmake
@@ -144,6 +144,7 @@
 # == ===
=
 # ``c_restrict``  ``PREFIX_RESTRICT``   ``restrict``
 # ``cxx_constexpr``   ``PREFIX_CONSTEXPR``  ``constexpr``
+# ``cxx_relaxed_constexpr``   ``PREFIX_RELAXED_CONSTEXPR``  ``constexpr``
 # ``cxx_deleted_functions``   ``PREFIX_DELETED_FUNCTION``   ``= delete``
 # ``cxx_extern_templates````PREFIX_EXTERN_TEMPLATE````extern``
 # ``cxx_final``   ``PREFIX_FINAL``  ``final``
@@ -494,6 +495,16 @@ function(write_compiler_detection_header
 #  endif
 \n)
   endif()
+  if (feature STREQUAL cxx_relaxed_constexpr)
+set(def_value ${prefix_arg}_RELAXED_CONSTEXPR)
+set(file_content ${file_content}
+#  if ${def_name}
+#define ${def_value} constexpr
+#  else
+#define ${def_value}
+#  endif
+\n)
+  endif()
   if (feature STREQUAL cxx_final)
 set(def_value ${prefix_arg}_FINAL)
 set(file_content ${file_content}
-- 

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] [PATCH] Macro generation for relaxed constexpr

[Jean-Michaël Celerier]

 I think there should be a test for the different allowed contexts of the
${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could
you extend Tests/Module/WriteCompilerDetectionHeader with a test for that?

For sure, I'll do this asap.

 constexpr foo = ...;

If I read http://en.cppreference.com/w/cpp/language/constexpr
correctly, there should be no differences in variable handling between
C++11 and 14 for constexpr, the changes are only for function bodies.



Jean-Michaël


On Wed, Jul 8, 2015 at 9:49 PM, Stephen Kelly steve...@gmail.com wrote:
 Stephen Kelly wrote:

 * A method marked constexpr will fail to compile with a compiler which
 does not support relaxed constexpr if the method uses language which
 requires relaxed mode (such as a for loop), even if the method is
 evaluated in a non- constant expression. I tested GCC and Clang.

 Are there any values of '...' where

  constexpr foo = ...;

 would compile or not depending only on whether using cxx11-constexpr or
 cxx14-constexpr?

 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
-- 

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