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
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
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 fil
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
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
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 simi
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 "${
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,
fin
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 s
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
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, bu
> 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 warn
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 store
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 p
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 pro
>> 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 (
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
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 s
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
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 a
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 warn
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
Kitwa
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 adde
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
@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
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 fi
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
27 matches
Mail list logo
