Re: [CMake] CMake IR

[Nicolas Desprès]

On Thu, Jul 30, 2015 at 1:51 PM, Nagy-Egri Máté Ferenc 
wrote:
[...]


> @Nicolas:
>
> Yes, these tools indeed have been working for the past few decades. Others
> also suggested why don’t I generate CMakelists.txt instead?
>
> The problem is that the current limitations of CMake all originate from
> the way the workflow is organized. Multi-configuration makefiles are
> trivial to implement if you do them by hand. All targets append the
> architecture after their name (app-x86, app-x64, lib-x86, etc.) and there
> were all-x86 and all-x64 targets, and there were the usual “all” target
> that references all-x86, all-x64. In CMake the workflow is baked into
> selecting an architecture at the earliest points in the configuration
> process and stores it as a global variable (state!) which then shoots all
> multi-configuration generators in the knee.
>
> Yes, it is possible to remove this limitation from CMake, but it would
> take roughly a year. Holding onto this limitation alone just because it is
> historically the way how CMake has been designed immediately rules it out
> from ~75% of application development going on in the world in the future
> (mobile app devel), which is funny because building cross-platform mobile
> apps is the future, and this is just the market that could benefit of CMake
> the most.
>

I always used CMake for generating Makefile targeting a single
architecture. I tried few times to generate Visual Studio project and XCode
project and my first impression was quite good. But I have not a lot of
experiences in this area. I agree with you that the users will need multi
architecture support more in the future.


-- 
Nicolas Desprès
-- 

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

Re: [CMake] [cmake-developers] CMake IR

[Eric Wing]

Disclaimer: My name is attached to the failed CMake/Lua attempt.

In principle, I like the idea of what you propose. However, in
practice, I think it might be too big and too ambitious.

Here are some quick thoughts I have:

- I am in the camp that I do not like the CMake language. And it is
often the hardest selling point in my experience, even when you
convince them that CMake can do all the cross-platform stuff. (I’m
seeing more competition from Gyp these days, but in my limited
personal experience, people still have not been able to port highly
complex projects to as many target platforms with Gyp, whereas CMake
could handle them (and the perceived gains of Gyp disappeared in these
complex scenarios)).

- Along those lines, part of the problem we seemed to hit was that
pure declarative build instructions didn’t hold up well in the complex
case. I haven’t done much with Gyp in this manner, but those around me
that were trying seemed to hit the wall pretty fast in this. But I
have used Ant, and that was a terrible experience for anything that
required conditionals.


- I would definitely like to see better interoperability with IDEs and
tools. I would personally love a simple cross-platform gui project
manager that basically allowed you to create targets, add/remove files
to be compiled to a target, and set specific compile/link flags on a
per-target or per-file basis, sort of like you can do in most IDEs
(but if you tried using CMake, your changes get clobbered in the next
regeneration…though even better would be able to do this directly in
the native IDEs).

- I am little concerned about encouraging people to add on any
arbitrary language. There are two different problems that this could
potentially cause: (1) CMake bloat, (2) Dependency hell

- CMake currently can bootstrap itself with just a C++ compiler. That
is a good thing. I recently had to get CMake up on a Raspberry Pi. I
was fortunate that CMake had few dependencies and was relatively
small. (Not counting Qt which was an unmitigated disaster.)

- Building other projects using CMake can be painful depending on
their dependency chain. While this is not technically CMake’s
responsibility, encouraging users to use non-canonical tools can make
things a nightmare. CMake has been pretty good about providing
fundamental mechanisms you need that work on all platforms. But if
users are encouraged to say, “I’ll just use Perl+CPAN or Ruby with
these gems”, instead of the standard CMake mechanisms, things get
awful quickly. (I finally just reproduced a build of JavaScriptCore
for Windows after over a year of trying…it has dependencies on Perl,
Python, Ruby, and a bunch of other things I can’t remember, all of
which are a terrible pain to get working on Windows.)

- In that same line of thought, the reason Lua was a good candidate is
because it its tiny which avoids adding bloat, it is pure ANSI C,
which means it compiles everywhere CMake already compiles, and it was
designed to be an embedded scripting language doing the exact type of
things that the current CMake language is asked to do. (Dr. Ken Martin
said they were impressed with Lua and would have used it if they had
known about it originally.)

(By the way, if you haven,t already, I encourage you to read through
the old Lua threads circa 2008.)

- Incidentally, the Lua table is pretty much the same
concept/pre-cursor to JSON in JavaScript. Lua lends it self to both
data driven formats as well as custom DSLs pretty well. If Lua were
part of the core, you could build a  the data-oriented format files
without any additional dependencies.


- I don’t think the IR will help anything related to the work of
adding new languages like Swift. The hard part there is not really the
CMake language as much as understanding the overall system
design/architecture. No matter what language you pick, that part will
always be hard.


- Mostly, I’m concerned that this project is too big and ambitious in
scope to see completion unless you have funding and a team to drive
it. The Lua attempt is a failure, but not for technical reasons. It
was a manpower problem. Dr. Ken Martin proved the concept could work
in something like 13 hours. But at the time Kitware said they weren’t
going to go down that road, so anybody still interested in it was left
to make it happen ourselves. We gave it a shot, but none of us really
had the time to commit to finish the task, which is much smaller than
the one you are proposing. (Granted, we wasted a lot of time trying to
bridge CVS (which CMake was still using at the time) with DVCS, so you
at least won’t have to worry about constant merge-hell.)


-Eric
-- 

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 Co

Re: [CMake] List of files not containing string

[David Cole via CMake]

Get the list of all files, loop over them, and filter out the ones
that DO have the string in the name ...?



On Thu, Jul 30, 2015 at 4:05 PM, Crast, Nicholas
 wrote:
> All,
>
>
>
> This seems like a pretty simple task, but I cannot figure out a good way to
> do it. I want to get a list of all files in a directory that do not have a
> certain string in the filename.
>
>
>
> Can someone help?
>
>
>
> -Nick
>
>
>
> 
>
> Nick Crast
>
> Software Engineer
>
> Saab Sensis Corporation
>
> Phone: 315-445-5703
>
> Email: nicholas.cr...@saabsensis.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://public.kitware.com/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://public.kitware.com/mailman/listinfo/cmake

[CMake] List of files not containing string

[Crast, Nicholas]

All,

This seems like a pretty simple task, but I cannot figure out a good way to do 
it. I want to get a list of all files in a directory that do not have a certain 
string in the filename.

Can someone help?

-Nick


Nick Crast
Software Engineer
Saab Sensis Corporation
Phone: 315-445-5703
Email: nicholas.cr...@saabsensis.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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] [cmake-developers] CMake IR

[Alexander Neundorf]

On Wednesday, July 29, 2015 07:49:07 Nagy-Egri Máté Ferenc via cmake-
developers wrote:
...
> I believe CMake is an invaluable tool, but it could do far better. 0/10
> CMake users I’ve met say they are “happy” CMake users. The learning curve
> is steep, and the skills gained are not reusable. CMake could gain even
> greater momentum (not by ditching, but) by offering alternate input
> languages with entities (classes, functions, macros, etc.) that feel
> natural in the given context.

Well, the cmake language is not really pretty, but in my experience it is 
usually good enough. Having a somewhat better language like e.g. Lua may be a 
good thing.
There is actually an advantage in not thaving a full-featured scripting 
language: users are less tempted to turn the build scripts into actual 
"programs" containing logic and doing a lot of stuff.
I have seen that happen with scons builds... as developer you had to 
understand two programs: the actual software, and the build "program".

There were already experiments with Lua and also with Javascript for cmake, 
but they didn't succeed so far.

Alex

-- 

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

Re: [CMake] BundleUtilities not working

[Bill Somerville]

On 30/07/2015 19:36, Rashad M wrote:

Hi all,

Hi Rashad


We have a similar way here to get dll dependencies recursively and 
create a zip archive. Ideally, this could be integrated in cmake but 
not sure if that will be ok on cmake side. The code doesn't uses 
fixup_bundle(..) but follows a similar function syntax.


 package_mingw(
ARCH "${mxearch}"
MXEROOT "${mxeroot}"
 PREFIX_DIR "${archive_name}"
 PEFILES  "${pefiles}"
SEARCHDIRS "")
more details here: 
https://git.orfeo-toolbox.org/otb.git/blob/HEAD:/CMakeLists.txt#l422
Note: this was only tested on a cross compiling build and contains 
some code specific for our project.


[1] 
https://git.orfeo-toolbox.org/otb.git/blob/HEAD:/CMake/MinGWPackage.cmake
That is all very Windows specific CMake already uses the same technique 
as your code but in a more platform independent way. You may want to 
consider optimizing in the same way as has been added to the 
BundleUtilities.cmake helper GetPrerequisites.cmake in:


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f01a8823

since the objdump -p output on large framework libraries like Qt (1+ 
lines) is very inefficient when processed as a CMake variable. In our 
CMake built Qt5 project we are getting huge speed ups on the install 
phase on Windows with this change.


Regards
Bill Somerville.



On Tue, Jul 28, 2015 at 7:04 PM, Brad King > wrote:


On 07/28/2015 12:51 PM, Bill Somerville wrote:
> The possible lack of grep is a potential issue so your read
> back from file suggestion is interesting, is there a recognized
place to
> write temporary files like this?

IIRC the code in question runs during "cmake -P cmake_install.cmake"
scripts so CMAKE_CURRENT_BINARY_DIR may be a reasonable choice.
If for any reason you need to randomize the file name then you
could use string(RANDOM).

Since this is specific to Windows perhaps $ENV{TEMP} will be useful,
though I don't recall off the top of my head whether applications
are supposed to read that directly.  Certainly a randomized file
name would be needed if a shared temp dir were used.

-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




--
Regards,
   Rashad


-- 

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

Re: [CMake] BundleUtilities not working

[Rashad M]

Hi all,

We have a similar way here to get dll dependencies recursively and create a
zip archive. Ideally, this could be integrated in cmake but not sure if
that will be ok on cmake side. The code doesn't uses fixup_bundle(..) but
follows a similar function syntax.

 package_mingw(
ARCH "${mxearch}"
MXEROOT "${mxeroot}"
 PREFIX_DIR "${archive_name}"
 PEFILES  "${pefiles}"
SEARCHDIRS "")

more details here:
https://git.orfeo-toolbox.org/otb.git/blob/HEAD:/CMakeLists.txt#l422

Note: this was only tested on a cross compiling build and contains some
code specific for our project.

[1]
https://git.orfeo-toolbox.org/otb.git/blob/HEAD:/CMake/MinGWPackage.cmake

On Tue, Jul 28, 2015 at 7:04 PM, Brad King  wrote:

> On 07/28/2015 12:51 PM, Bill Somerville wrote:
> > The possible lack of grep is a potential issue so your read
> > back from file suggestion is interesting, is there a recognized place to
> > write temporary files like this?
>
> IIRC the code in question runs during "cmake -P cmake_install.cmake"
> scripts so CMAKE_CURRENT_BINARY_DIR may be a reasonable choice.
> If for any reason you need to randomize the file name then you
> could use string(RANDOM).
>
> Since this is specific to Windows perhaps $ENV{TEMP} will be useful,
> though I don't recall off the top of my head whether applications
> are supposed to read that directly.  Certainly a randomized file
> name would be needed if a shared temp dir were used.
>
> -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
>



-- 
Regards,
   Rashad
-- 

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

Re: [CMake] [cmake-developers] CMake IR

[Bill Hoffman]

On 7/30/2015 11:56 AM, Dan Kegel wrote:

I believe the latter, but not the former.
I never use the GUI, and consider the cache an anti-feature there solely
to support GUI users.  It complicates my life, and I'd love to see it go.
It is certainly not there just for the GUI.  Every try-compile, 
find_library, find_program result is stored there as well.  If you did 
this each time, it would be not only slow to re-run a build, but it 
might come up with different answers each time.   If it went it would 
complicate your life even more.   In what way do you think it is causing 
you trouble?


Also, CMake needs to be able to auto-rerun when its input changes and 
this is how the command line -D options are saved along with all the 
other system introspection results.


-Bill

--

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

Re: [CMake] [cmake-developers] CMake IR

[Michael Jackson]

On Jul 30, 2015, at 11:56 AM, Dan Kegel  wrote:

> 
> Am 30.07.2015 10:15 vorm. schrieb "Bill Hoffman" :
> >
> > On 7/30/2015 10:48 AM, Dan Kegel wrote:
> >>
> >> I wouldn't mind getting rid of the cache, it's a bizarre concept that 
> >> appears
> >> to be a workaround for users who can't stand starting cmake from a script,
> >> and it complicates my cmake scripts, but that's not a battle I'd like to 
> >> wage.
> >
> > No, it is how CMake stores things it finds during the configure step. If 
> > you did not have it you would have to rediscover everything for every run 
> > on a build tree, and have no place to store user selections in the GUI.
> 
> I believe the latter, but not the former.
> I never use the GUI, and consider the cache an anti-feature there solely to 
> support GUI users.  It complicates my life, and I'd love to see it go.
> 

Which don't you believe? The part where if you don't have a cache then you have 
to rediscover everything? Simply delete the CMakeCache.txt file and rerun 
CMake. You will rediscover everything. If you do not have some sort of "state 
file" then exactly how would one store their selections? Since you are 
comfortable on the command line I'll assume you love typing:

cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/usr/foo 
-DCXX_COMPILE_FLAGS=All -DKEEP_GOING_WITH_EVEN_MORE_ARGUMENTS -G Ninja 
../YourProject.

For shorter invocations this isn't so bad to type. We have our project down to 
a single argument, but we preload from, wait for it, a cache file. But what 
about those folks who are simply NOT comfortable on the command line and always 
use the GUI? If CMake _never_ had a GUI then your argument might have some 
merit.

If your next thought is something like ".. Well just write an alias in your 
.bashrc so you do not have to type it out each time.." then didn't you just 
basically create a "cache" file?

And if you vote for "just rediscover everything, every time" then you have 
never run CMake on a larger project on a Windows machine with Visual Studio. 
Now _that_ is slow. I think the history of the design implementations kind of 
shows that a Cache is more helpful than hurtful.

Plus when Project developers decide to hard code their own version of dependent 
libraries and give you no way of over riding those settings OTHER than hand 
editing the cache file, then be thankful you have the cache file there.

Just my 2 cents.

Mike Jackson


-- 

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

Re: [CMake] [cmake-developers] CMake IR

[Geoffrey Viola]

I think this topic addresses improving the greatest CMake's greatest weakness.

> It would modularize the internals of CMake in a cleaner fashion
Good point. Having built part of a generator, I would appreciate cleaner 
generator interfaces. That way it's clear what implementations are necessary to 
support which CMake features.

> The big selling point would be the ability to introduce arbitrary front-ends 
> to CMake, not just CMakelists.txt. Every developer could choose an input 
> language that suits their project/needs/skills.
When trying to get a team to adopt CMake, learning this new language is a 
barrier for entry. Doing a trade study on build tools made SCons looks pretty 
good because it is in python, but ultimately we decided on CMake because I used 
it before.

Geoffrey Viola
SOFTWARE ENGINEER
asirobots.com

This message contains confidential information and is intended only for the 
recipient. If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately if you 
have received this e-mail by mistake and delete this e-mail from your system. 
Finally, the recipient should check this email and any attachments for the 
presence of viruses. The company accepts no liability for any damage caused by 
any virus transmitted by this email.
-- 

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

Re: [CMake] [cmake-developers] CMake IR

[Dan Kegel]

Am 30.07.2015 10:15 vorm. schrieb "Bill Hoffman" :
>
> On 7/30/2015 10:48 AM, Dan Kegel wrote:
>>
>> I wouldn't mind getting rid of the cache, it's a bizarre concept that
appears
>> to be a workaround for users who can't stand starting cmake from a
script,
>> and it complicates my cmake scripts, but that's not a battle I'd like to
wage.
>
> No, it is how CMake stores things it finds during the configure step. If
you did not have it you would have to rediscover everything for every run
on a build tree, and have no place to store user selections in the GUI.

I believe the latter, but not the former.
I never use the GUI, and consider the cache an anti-feature there solely to
support GUI users.  It complicates my life, and I'd love to see it go.
-- 

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

Re: [CMake] Making and using static and shared libraries on Windows with Visual Studio

[rleigh]

> Did you try to remove all the explicit template exports? I never had to do
> it and compiled many static and shared libraries on Windows. Of course VS
> is going to complain about exporting template classes but as long as you
> don't try to mix VS versions I think you can safely ingore those warnings.

Thanks for the suggestions.  The above seems true, though I think I'll
likely retain it for DLL builds and lose it for static builds.  If nothing
else it removes the warnings and will hopefully make it safer for
corner-case failures by end users of the library?  Hopefully MSVC is
clever enough to elide duplicate instantiations when it links the DLL?

Relating to CMake, the guidance from Microsoft for correctly exporting
templates here: https://support.microsoft.com/en-us/kb/168958
uses an foo_EXPORT_TEMPLATE macro in addition to foo_EXPORT.  This is
basically empty in the DLL for export, and "extern" for imports.  I wonder
if this is something that GenerateExportHeader should be generating in
addition to the typical export macro?


Regards,
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/opensource/opensource.html

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

Re: [CMake] [cmake-developers] CMake IR

[Bill Hoffman]

On 7/30/2015 10:48 AM, Dan Kegel wrote:

I wouldn't mind getting rid of the cache, it's a bizarre concept that appears
to be a workaround for users who can't stand starting cmake from a script,
and it complicates my cmake scripts, but that's not a battle I'd like to wage.
No, it is how CMake stores things it finds during the configure step. 
If you did not have it you would have to rediscover everything for every 
run on a build tree, and have no place to store user selections in the 
GUI.


-Bill

--

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

Re: [CMake] [cmake-developers] CMake IR

[Dan Kegel]

On Thu, Jul 30, 2015 at 9:30 AM, David Cole  wrote:
> json is SOOO much sexier than XML. ;-)

shiny, shiny json :-)

Agreed, json is not covered with ugly-stink.  I like it and use it daily.

I'm not at all sure that stateless build languages are a win in the
multiplatform general case.
They  probably work well as a way to feed parameters to a single build backend,
but not so good as a way to handle multiple backends.
gyp is one attempt to do this, and it worked, but it's painful to use
and requires deep
understanding of the gyp model.

So, +1 for the idea of adding a better language on the side of cmake,
-1 for adding multiple languages (especially anything from Microsoft), and
-1 for going fully stateless.

I wouldn't mind getting rid of the cache, it's a bizarre concept that appears
to be a workaround for users who can't stand starting cmake from a script,
and it complicates my cmake scripts, but that's not a battle I'd like to wage.
- Dan
-- 

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

Re: [CMake] [cmake-developers] CMake IR

[David Cole via CMake]

json is SOOO much sexier than XML. ;-)

On Thu, Jul 30, 2015 at 10:10 AM, Dan Kegel  wrote:
>>> The big selling point would be the ability to introduce arbitrary
>>> front-ends to CMake, not just CMakelists.txt. Every developer could
>>> choose an input language that suits their project/needs/skills.
>>
>> I don't like that idea.
>>
>> Many different languages would make supporting (as in helping
>> someone with his project) and understanding arbitrary CMake projects much 
>> harder.
>
> +1
>
> Also, adding XML of any sort to CMake would instantly taint it with 
> ugly-stink.
> --
>
> 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
-- 

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

Re: [CMake] [cmake-developers] CMake IR

[Dan Kegel]

>> The big selling point would be the ability to introduce arbitrary
>> front-ends to CMake, not just CMakelists.txt. Every developer could
>> choose an input language that suits their project/needs/skills.
>
> I don't like that idea.
>
> Many different languages would make supporting (as in helping
> someone with his project) and understanding arbitrary CMake projects much 
> harder.

+1

Also, adding XML of any sort to CMake would instantly taint it with ugly-stink.
-- 

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

Re: [CMake] Passing generator expressions in variables

[Auer, Jens]

Just to add to my question: I do not expect that set(alib 
"$") expands to the list of files, I just want to pass the 
string "$" to add_executable and then evaluate it there.


From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Auer, Jens
Sent: 30 July 2015 09:15
To: cmake@cmake.org
Subject: [CMake] Passing generator expressions in variables

Hi,

I am trying to dynamically assemble a list of generator expressions and use 
them in add_executable. The background is that I have some macros to add 
targets, e.g.
add_my_library(TARGET liba SOURCES ...) # this class add_library(liba OBJECT 
...) internally
add_my_executable(TARGET a DEPENDS liba libb SOURCES ...)

In add_my_executable, I create a list of $ strings for all 
d {liba, libb}. However, cmake complains that it cannot find the source file 
$.

A simplified example of what I want to do is this:
add_library(A OBJECT a.cpp)
set(alib $ )

With cmake 3.2.2, the first add_executable fails, the second one works. Is 
there another way to do this?

Best wishes,
  Jens

--
Dr. Jens Auer | CGI | Software Engineer
CGI Deutschland Ltd. & Co. KG
Rheinstraße 95 | 64295 Darmstadt | Germany
T: +49 6151 36860 154
jens.a...@cgi.com
Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter 
de.cgi.com/pflichtangaben.

CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI 
Group Inc. and its affiliates may be contained in this message. If you are not 
a recipient indicated or intended in this message (or responsible for delivery 
of this message to such person), or you think for any reason that this message 
may have been addressed to you in error, you may not use or copy or deliver 
this message to anyone else. In such case, you should destroy this message and 
are asked to notify the sender by reply e-mail.

-- 

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

Re: [CMake] CMake finds wrong ar/ranlib/nm

[Auer, Jens]

I did some more investigation and found out that this only happens when I use 
CMAKE_BUILD_TYPE=RELEASE. Could this be related to the bug in centos? When I 
set the build type to release, ar crashes when using lto. Could this make cmake 
discard the ar in the custom directory and fall-back to the system one?

Best wishes,
  Jens

--
Dr. Jens Auer | CGI | Software Engineer
CGI Deutschland Ltd. & Co. KG
Rheinstraße 95 | 64295 Darmstadt | Germany
T: +49 6151 36860 154
jens.a...@cgi.com
Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter 
de.cgi.com/pflichtangaben.

CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI 
Group Inc. and its affiliates may be contained in this message. If you are not 
a recipient indicated or intended in this message (or responsible for delivery 
of this message to such person), or you think for any reason that this message 
may have been addressed to you in error, you may not use or copy or deliver 
this message to anyone else. In such case, you should destroy this message and 
are asked to notify the sender by reply e-mail.


> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Hoffman
> Sent: 30 July 2015 15:27
> To: cmake@cmake.org
> Subject: Re: [CMake] CMake finds wrong ar/ranlib/nm
> 
> On 7/30/2015 3:17 AM, Auer, Jens wrote:
> > Thanks a lot. Obviously, setting the environment when calling cmake is
> > not enough. The command scl enable devtoolset-3 "cmake ../src"
> > sets the path etc and runs the cmake command, but it seems that cmake
> > opens a new subshell with default settings. I've added the settings to
> > .bashrc and it now finds the correct ar/ranlib etc.
> I don't believe it.  CMake does not open a new shell, something else is going 
> on.
> Sounds like you have other system problems to deal with.
> 
> -Bill
> 
> 
> 
> --
> 
> 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
-- 

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

Re: [CMake] [cmake-developers] CMake IR

[Nils Gladitz]

On 07/29/2015 09:49 AM, Nagy-Egri Máté Ferenc via cmake-developers wrote:

  *
The big selling point would be the ability to introduce arbitrary
front-ends to CMake, not just CMakelists.txt. Every developer could
choose an input language that suits their project/needs/skills.


I don't like that idea.

Many different languages would make supporting (as in helping someone 
with his project) and understanding arbitrary CMake projects much harder.


I would certainly be for adding a single additional script language 
though. I am personally still rooting for Lua.


Nils
--

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

Re: [CMake] CMake IR

[Bill Hoffman]

On 7/30/2015 7:51 AM, Nagy-Egri Máté Ferenc via CMake wrote:

Bill:

I am a member, I just tried sending using the same mail using
the “secret CC” option. It seems it did not work.


OK, I just checked and it was rejected because of this:

Reason: Message has implicit destination

I have approved it, but if you could send directly to the list that 
would be better as I don't look at the rejected posts that often.


-Bill
--

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

Re: [CMake] Making and using static and shared libraries on Windows with Visual Studio

[Guillaume Dumont]

Roger,

Did you try to remove all the explicit template exports? I never had to do
it and compiled many static and shared libraries on Windows. Of course VS
is going to complain about exporting template classes but as long as you
don't try to mix VS versions I think you can safely ingore those warnings.

Also, this block of code in a.h, b.h, etc.:

#ifndef A_H
#define A_H

#include 
#include "aexport.h"

#ifdef a_BUILT_AS_STATIC
#  define a_EXPORT_TEMPLATE
#else
#  ifndef a_EXPORT_TEMPLATE
#ifdef a_EXPORTS
/* We are building this library */
#  define a_EXPORT_TEMPLATE
#else
/* We are using this library */
#  define a_EXPORT_TEMPLATE extern
#endif
#  endif

#  ifndef A_NO_EXPORT
#define A_NO_EXPORT
#  endif
#endif

#ifdef _MSC_VER
// Explicit template exports.
#include 
a_EXPORT_TEMPLATE template class a_EXPORT std::allocator;
a_EXPORT_TEMPLATE template struct a_EXPORT std::char_traits;
a_EXPORT_TEMPLATE template class a_EXPORT std::basic_string, std::allocator >;
#endif

class a_EXPORT a
{
  std::string val;

 public:
  a();

  std::string const&
  getval() const;
};

#endif // A_H


seems redundant. I would remove it. Including aexport.h should be enough.

Hope this helps.

Guillaume

On Thu, Jul 30, 2015 at 8:45 AM, Roger Leigh  wrote:

> ibraries which





-- 
Guillaume Dumont
=
dumont.guilla...@gmail.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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Making and using static and shared libraries on Windows with Visual Studio

[rleigh]

It turns out this was my fault: removing the instantiation/export of

  std::char_traits

was sufficient to correct the linker errors.

Sorry for the noise,
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/opensource/opensource.html

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

Re: [CMake] CMake finds wrong ar/ranlib/nm

[Bill Hoffman]

On 7/30/2015 3:17 AM, Auer, Jens wrote:

Thanks a lot. Obviously, setting the environment when calling cmake
is not enough. The command scl enable devtoolset-3 "cmake ../src"
sets the path etc and runs the cmake command, but it seems that cmake
opens a new subshell with default settings. I've added the settings
to .bashrc and it now finds the correct ar/ranlib etc.
I don't believe it.  CMake does not open a new shell, something else is 
going on.  Sounds like you have other system problems to deal with.


-Bill



--

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

[CMake] Making and using static and shared libraries on Windows with Visual Studio

[Roger Leigh]

Hi folks,

This might not be a problem with CMake, it's probably due to my lack of 
familiarity with Windows either in CMakeLists.txt or in the code itself. 
 I have a large C++ codebase which uses CMake to build on 
Linux/Unix/MacOS X.  I'm currently porting it to use a superbuild 
infrastructure to build on Windows.  The superbuild works fine, but I'm 
running into odd linking errors.


I've tried to create a minimal testcase to demonstrate the problem. 
This is here: https://github.com/rleigh-dundee/dlltest

(test-vs201n.bat will run cmake and the builds automatically)

This creates a few libraries which contain classes using std::string or 
std::vector and then links them into test programs.  It's 
really trivial, and works fine on non-Windows systems, but fails when 
linking static libs on Windows.


With Windows, I see this:

   Shared  Static
  VS2012   FailFail
  VS2013   WorksFail
  VS2015   Warns   Fail

VS2012 has problems parsing the code, which looks like a VS2012 bug 
needing workaround, and the VS2015 DLL warning looks like some change in 
the internal implementation details of string and vector.  What's 
concerning me is that I'm getting link errors along the lines of:


c.lib(c.obj) : error LNK2019: unresolved external symbol "public: static 
unsigned __int64 const std:: basic_stringstd::char_traits,class std::allocator >::npos 
(?npos@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@2_KB) referenced 
in function "class std::basic_stringstd::char_traits,class std::allocator > * __cdecl 
std::_Uninit_copystd::char_traits,class std::allocator > const *,class 
std::basic_string,class 
std::allocator > *,class std::allocator<
class std::basic_string,class 
std::allocator > > >(class std::basic_stringstd::char_traits,class std::allocator > const *,class 
std::basic_string,class 
std::allocator > const *,class std::basic_stringstd::char_traits,class std::allocator > *,struct 
std::_Wrap_allocstd::basic_string,class 
std::allocator > > > &,struct std::_Nonscalar_ptr_iterator_tag)" 
(??$_Uninit_copy@PEBV?$basic_string@DU?$char_traits 
@D@std@@V?$allocator@D@2@@std@@PEAV12@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@YAPEAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@0@PEBV10@0PEAV10@AEAU?$_Wrap_alloc@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@std@@@0@U_Nonscalar_ptr_iterator_tag@0@@Z) 
[C:\Users\rleigh\libtest\2013s\testc.vcxproj]
c.lib(c2.obj) : error LNK2001: unresolved external symbol "public: 
static unsigned __int64 const std::basic_stringstd::char_traits,class std::allocator >::npos" 
(?npos@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@2_KB) [C:\Users\rleigh\libtest\2013s\testc.vcxproj]


The odd thing: this only occurs for libraries "c" and "d" using 
std::vector while libraries "a" and "b" using std::string 
work just fine--I'm not sure what exactly is using npos unless it's part 
of the vector default construction of string.


Could any CMake users with Windows expertise possibly suggest what I'm 
doing wrong or missing here, either in the CMake logic or in the code. 
I thought I had all the template instantiations right for DLL export, 
but thought static libraries would Just Work!



Many thanks,
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/opensource/opensource.html

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

Re: [CMake] CMake IR

[Nagy-Egri Máté Ferenc via CMake]

@Domagoj:


“In addition to it feeling like working with (or fighting against) an ugly 
crossover between a C preprocessor and a shell script from 1979, an 
increasingly 
big source of frustration is its rigidness and limitation of 'only one 
toolset/compiler per project'.”


😃 I couldn’t have put it any better myself.


Indeed, I recently had the idea of writing a Windows Store XAML application to 
give a GUI frontend to TagLib, just as an excercise and give it a jump start in 
August on my vacation when I want to do something productive. I started 
collecting the dependencies and everything, and came across… CMake has Windows 
Store support, but how on Earth am I going to build x86/x64/ARM targets from 
one VS solution? I was reading the docs a while and said to mysef “ah, f*ck it, 
no CMake has nothing to do here.” It is very annoying that CMake has these 
limitation at it’s very core that would take months and months to rule out. I 
can imagine Android being even more painful in this regard. CMake really could 
do a whole lot better in this.


@Nicolas:


Yes, these tools indeed have been working for the past few decades. Others also 
suggested why don’t I generate CMakelists.txt instead?


The problem is that the current limitations of CMake all originate from the way 
the workflow is organized. Multi-configuration makefiles are trivial to 
implement if you do them by hand. All targets append the architecture after 
their name (app-x86, app-x64, lib-x86, etc.) and there were all-x86 and all-x64 
targets, and there were the usual “all” target that references all-x86, 
all-x64. In CMake the workflow is baked into selecting an architecture at the 
earliest points in the configuration process and stores it as a global variable 
(state!) which then shoots all multi-configuration generators in the knee.


Yes, it is possible to remove this limitation from CMake, but it would take 
roughly a year. Holding onto this limitation alone just because it is 
historically the way how CMake has been designed immediately rules it out from 
~75% of application development going on in the world in the future (mobile app 
devel), which is funny because building cross-platform mobile apps is the 
future, and this is just the market that could benefit of CMake the most.


@Bill:


I am a member, I just tried sending using the same mail using the “secret CC” 
option. It seems it did not work.


@David:


Maybe some convincing and positive feedback can do the trick. I mostly live my 
life on Windows, so most technologies and tools relate to Windows, but all the 
HPC clusters I use are linux, hence the need for CMake. My initial research 
builded down to this:


Learn from the ‘competition’


Identify the portable properties of building a C++ application (mostly from 
CMake) and define an XML Schema.


Create the Schema of a chosen compiler


Implementing everything in C++


Initially do not bother with a front-end. Using the Schema, Visual Studio can 
provide Intellisense based on the .xsd file. This is sufficient for dev 
pourposes.


Using this open-source lib, getting a parser/deserializer and datastructure for 
use in C++ is as easy as 1-2-3.


Use the aforementioned lib to get a datastructure and serializer using the 
MSBuild Schema.


Almost done. Just wrap the Schemas of the IR into neat C++ classes. Tadaaa: C++ 
front-end.


Wrap the C++ classes with C++/CX for use with Powershell. Tadaaa: Powershell 
front-end.


Implement everything in PS (just for kicks)


PS alread understands the [xml] type and can read/write and process it. 
Validation can be used from PSCX.


Transform the data read into MSBuild’s own. (Somewhat blindly, because there 
are no neat classes available in the MSBuild Schema format)


Amost done. Write PS5 classes around the Schema entities. Tadaaa: PS front-end.



Future work:

Make it better


Implement other generators after the all too convenient, XML based MSBuild.


Add Unit Test Schemas


Add packaging Schemas (Nuget is again XML based with XSD Schema, trivial to 
implement)


Enhance package support to be able to fetch dependencies from git and build (a 
la Cargo), have installation method similar to CMake packages, etc.



If the entire build’s information is available as an iterable C++ tree-like 
datastructure, how hard can it be to implement generators like Ninja? (Not 
trivial, but not hard either.) If there is a clear Schema of valid options for 
a specific feature, so many things simplify. Again, imagine automatic fetching 
of dependencies from multiple repositories even. Nuget, GitHub, .deb, you name 
it!


And I haven’t even mentioned things like remote builds and what not… all new 
features could be introduced as a seperate Schema with it’s respective options, 
and if the user references the schema in the IR, and the generator supports it, 
it is done. Imagine distributed builds similar to Incredibuild, but with CMake. 
Nothing is needed, but the user define a pool of machines, a

Re: [CMake] CMake finds wrong ar/ranlib/nm

[Auer, Jens]

Thanks a lot. Obviously, setting the environment when calling cmake is not 
enough. The command scl enable devtoolset-3 "cmake ../src"
sets the path etc and runs the cmake command, but it seems that cmake opens a 
new subshell with default settings. I've added the settings to .bashrc and it 
now finds the correct ar/ranlib etc.

Unfortunately,  this uncovered a bug in binutils on my system (centos 7) which 
results in a segfault when using ar to create a static lib with 
link-time-optimizations enabled. As a workaround, I tried to convert the 
library targets to OBJECT libraries, which also makes sense because I use the 
libraries to structure my project only. They are not delivered. However, this 
resulted in another problem with generator expressions. I will post another 
question for that.

Thanks,
  Jens

--
Dr. Jens Auer | CGI | Software Engineer
CGI Deutschland Ltd. & Co. KG
Rheinstraße 95 | 64295 Darmstadt | Germany
T: +49 6151 36860 154
jens.a...@cgi.com
Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter 
de.cgi.com/pflichtangaben.

CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI 
Group Inc. and its affiliates may be contained in this message. If you are not 
a recipient indicated or intended in this message (or responsible for delivery 
of this message to such person), or you think for any reason that this message 
may have been addressed to you in error, you may not use or copy or deliver 
this message to anyone else. In such case, you should destroy this message and 
are asked to notify the sender by reply e-mail.


-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Hoffman
Sent: 28 July 2015 17:05
To: cmake@cmake.org
Subject: Re: [CMake] CMake finds wrong ar/ranlib/nm

On 7/28/2015 4:39 AM, Auer, Jens wrote:
> Hi,
>
> I am trying to use another compiler than the default one installed on 
> my system. I have to do this because I want to use a newer gcc than 
> the one on centos 7,so I installed RedHat Developer Toolset 3 with gcc 
> 4.9. When I call cmake with
>
> sclenable devtoolset-3 "cmake ../src" in my build directory, it 
> generates makefiles which use the new compiler and linker, but still 
> uses the default /usr/bin/ar etc. This is problematic because I enable 
> whole-program-optimization in release mode, and this needs to use the 
> ar provided with gcc 4.9 to handle the link-time optimization object files.
>
> I have tried various things to force cmake to use a specific ar, but 
> none of these worked:
>
> -Manually set CMAKE_AR in the CMakeLists.txt
>
> -Change CMAKE_AR in the cache
>
> -Write my own toolchain file
>
> With the toolchain file, cmake creates Makefiles but puts an empty ar 
> command in the lib "link" command, and building thus fails with an error.
>
> Am I missing something?
>
This is an environment thing.  Make sure the command line you are using is 
setup to find the other tools first in your PATH and it should work. 
  CMake assumes the environment is setup to work with the compiler you want to 
use.

-Bill

-- 

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

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

[CMake] Passing generator expressions in variables

[Auer, Jens]

Hi,

I am trying to dynamically assemble a list of generator expressions and use 
them in add_executable. The background is that I have some macros to add 
targets, e.g.
add_my_library(TARGET liba SOURCES ...) # this class add_library(liba OBJECT 
...) internally
add_my_executable(TARGET a DEPENDS liba libb SOURCES ...)

In add_my_executable, I create a list of $ strings for all 
d {liba, libb}. However, cmake complains that it cannot find the source file 
$.

A simplified example of what I want to do is this:
add_library(A OBJECT a.cpp)
set(alib $ )

With cmake 3.2.2, the first add_executable fails, the second one works. Is 
there another way to do this?

Best wishes,
  Jens

--
Dr. Jens Auer | CGI | Software Engineer
CGI Deutschland Ltd. & Co. KG
Rheinstraße 95 | 64295 Darmstadt | Germany
T: +49 6151 36860 154
jens.a...@cgi.com
Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter 
de.cgi.com/pflichtangaben.

CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI 
Group Inc. and its affiliates may be contained in this message. If you are not 
a recipient indicated or intended in this message (or responsible for delivery 
of this message to such person), or you think for any reason that this message 
may have been addressed to you in error, you may not use or copy or deliver 
this message to anyone else. In such case, you should destroy this message and 
are asked to notify the sender by reply e-mail.

-- 

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