On Thu, Jan 28, 2016 at 3:36 PM, Ben Boeckel wrote:
> On Thu, Jan 28, 2016 at 15:15:58 -0500, Taylor Braun-Jones wrote:
>> That's too bad. I understand the perspective of the Ninja developers,
>> but it's not clear to me what the proposed alternative should be.
>> Should CMake be using the subninj
On Thu, Jan 28, 2016 at 15:15:58 -0500, Taylor Braun-Jones wrote:
> That's too bad. I understand the perspective of the Ninja developers,
> but it's not clear to me what the proposed alternative should be.
> Should CMake be using the subninja[1] keyword to include the
> build.ninja of External Proj
On Thu, Jan 28, 2016 at 11:28 AM, Nicolas Desprès
wrote:
> Unfortunately, Ninja won't offer it:
> https://github.com/ninja-build/ninja/pull/1079
That's too bad. I understand the perspective of the Ninja developers,
but it's not clear to me what the proposed alternative should be.
Should CMake be
Hi Jan,
On Thu, Jan 28, 2016 at 4:52 PM, 🐋 Jan Hegewald
wrote:
> Hi Andreas,
>
> > On 28.01.2016, at 16:43, Andreas Pakulat wrote:
> >
> > Hi Jan,
> >
> > On Thu, Jan 28, 2016 at 2:35 PM, 🐋 Jan Hegewald
> wrote:
> > Hi Nils,
> >
> > > On 28.01.2016, at 13:39, Nils Gladitz wrote:
> > >
> > > Y
On 01/28/2016 11:04 AM, Taylor Braun-Jones wrote:
> Is this expected behavior, a known bug, or a new bug that I should file?
Currently it is expected, but I don't think anyone has thoroughly
investigated it or tried to implement it. IIRC it works in Makefile
generators only because the make tool
On Sat, Mar 28, 2015 at 10:38 AM, Taylor Braun-Jones
wrote:
>
> See htop screenshot below for an example of what I mean. Note that
`ninja` in the original command line invocation is just a bash alias for
ninja-build (the name of the ninja binary on Fedora-based systems)
>
> Should I expect to see
Hi Andreas,
> On 28.01.2016, at 16:43, Andreas Pakulat wrote:
>
> Hi Jan,
>
> On Thu, Jan 28, 2016 at 2:35 PM, 🐋 Jan Hegewald wrote:
> Hi Nils,
>
> > On 28.01.2016, at 13:39, Nils Gladitz wrote:
> >
> > You might already be aware but CMake discourages using GLOB for source files
>
> yes, I
Hi Jan,
On Thu, Jan 28, 2016 at 2:35 PM, 🐋 Jan Hegewald
wrote:
> Hi Nils,
>
> > On 28.01.2016, at 13:39, Nils Gladitz wrote:
> >
> > You might already be aware but CMake discourages using GLOB for source
> files
>
> yes, I read the docs before posting (:
> Avoiding glob would be a workaround to
Hi Nils,
> On 28.01.2016, at 13:39, Nils Gladitz wrote:
>
> You might already be aware but CMake discourages using GLOB for source files
yes, I read the docs before posting (:
Avoiding glob would be a workaround to my problem. But anyway I think that glob
is broken if it produces different res
> Not sure how we can disable such script call from CPackRPM unless adding the
> extra feature to call
> rpm/rpmbuild wiht appropriate option. May be you can try to fill the
> CPACK_RPM_SPEC_MORE_DEFINE variable
> with appropriate macro redefining "__os_install_post".
>
> This would be more like a
2016-01-28 11:33 GMT+01:00 Attila Krasznahorkay <
attila.krasznahor...@gmail.com>:
> Dear All,
>
> This should be a simple question, but somehow I don't seem to find an
> answer to it with Google.
>
> Our projects have a lot of python files in them. Many of which are not
> simple python files. The
On 01/28/2016 12:56 PM, 🐋 Jan Hegewald wrote:
Hi all,
I have some trouble with file globbing using the glob command like so:
file(GLOB all_sources ${src_home}/*.F**)
You might already be aware but CMake discourages using GLOB for source
files; though for different reasons (see Note in
Hi,
Thanks Nils !
Regards,
Nikita
From: Nils Gladitz
Sent: 28 January 2016 05:27 PM
To: Nikita Barawade; cmake@cmake.org
Subject: Re: [CMake] Multiple Visual Studio Solutions through same master
CMakeLists.txt
On 01/28/2016 12:42 PM, Nikita Barawade wrote
Hi all,
I have some trouble with file globbing using the glob command like so:
file(GLOB all_sources ${src_home}/*.F**)
the src_home contains files with uppercase and also some with lowercase
suffixes, e.g. .F and .f (This makes an important difference to some Fortran
compilers regarding
On 01/28/2016 12:42 PM, Nikita Barawade wrote:
Hi All ,
It is possible to same master CMakeList to generate multiple visual
studio solution files ?
here is my master CMakeList :
cmake_minimum_required (VERSION 2.8.11)
project (Myproject_all)
set_property (GLOBAL PROPERTY USE_FOLDERS ON
Hi All ,
It is possible to same master CMakeList to generate multiple visual studio
solution files ?
here is my master CMakeList :
cmake_minimum_required (VERSION 2.8.11)
project (Myproject_all)
set_property (GLOBAL PROPERTY USE_FOLDERS ON)
# Set compiler flags and options.
# enable the Vis
I'm currently "fighting" with the relocation using cpack ...
When creating an executable AND a library resulting in
two RPM's with two different paths lets say ...
- /foo/bin/mybin| executable
- /usr/local/include| library headers
- /usr/local/lib64 | library binary file
That'
Dear All,
This should be a simple question, but somehow I don't seem to find an answer to
it with Google.
Our projects have a lot of python files in them. Many of which are not simple
python files. They are files that need our software to interpret them. So CPack
should just leave them alone.
A solution file is in my view just an aggregation of projects. So I expected it
to work in this context. Anyway, that leaves one question, how do I specify
configuration and platform for the include_external_msproject?
Using (below) does not work. I still get the error message "Please check to
19 matches
Mail list logo
