Hello,
sorry for the delayed reply. The root of the problem is actually not the XCtest
feature, but generator expressions. The minimal repro case is just the
following CMakeLists.txt file:
cmake_minimum_required(VERSION 3.5)
project(IosTarget C)
file(GENERATE
OUTPUT ${CMAK
I think it depends on when you want the output files from Nim
generated and which files are the most frequently developed.
If it is usually a one-time generation per clean development session,
the simplest case, where the *.NIM source files are not the files
most likely to be changed, I would think
Two days ago I posted this question on StackOverflow,
http://stackoverflow.com/q/36415261/3154588. I have not gotten an answer there,
so I thought I would ask on this list.
What are good ways to document my project ``CMakeLists.txt`` files and local
project ``.cmake`` files? There is a two yea
Ok, one part of the problem, I could solve. I could solve the problem
with running the following commands:
cmake . && make package
After that, I get a rpm package. But now, I have another problem and I
do not know, if I am doing something wrong or if this is a bug.
Let's assume, I have a library
Hi,
I have an error and I do not know, how to solve this error.
I have an archive, where are some files. I want to generate a rpm
package with the files, which are in that archive. So first, I extract
that archive with a bash script. After that, the script calls "cpack
-G RPM -V ." for this CMake
Ah, I thought cmake was controlling the output filenames of the compiler and
not Xcode. Then its not really a cmake problem. Changing source names is easy
enough. I was just curious. Also in the real case I could just as easily use a
STATIC library instead but normally go for OBJECT libraries fi
On 04/06/2016 03:47 PM, Gregor Jasny wrote:
> On 06/04/16 20:32, Matthew Keeler wrote:
>> clang: error: no such file or directory:
>> '.../lib/example.build/Debug/example.build/Objects-normal/x86_64/x.o'
>>
>> Within the directory
>> .../lib/example.build/Debug/example.build/Objects-normal/x86_64
On 06/04/16 20:32, Matthew Keeler wrote:
>
> I think I ran into a bug but I am wondering if anyone has seen it an worked
> around.
>
> I have a source structure like the following (this is a contrived small
> example to illustrate the problem):
>
> - CMakeLists.txt
> - main.c
> - lib
>
I think I ran into a bug but I am wondering if anyone has seen it an worked
around.
I have a source structure like the following (this is a contrived small example
to illustrate the problem):
- CMakeLists.txt
- main.c
- lib
- CMakeLists.txt
- x.c
- x.h
- alt1
- x.c
I found the same thing a few years ago, and my solution was the same: only
include those modules once. I find that my sub cmake modules are much cleaner
now as a bonus.
I tend to blame the time not on file IO, but on time to parse those files.
I've never done actual profiling though.
-Or
Okay, so I tried my own suggesting and found that it doesn't work at
all (it's more complicated than I thought). However I want to ask you
about your logic here - you say that when the configure step runs, it
cancels XCode's build and so the user has to run the build a second
time. If we use a scri
It turns out the problem was due to scoping. The module in question
was only being included by subdirectories, but not the top-level
listfile (I'm sure you can see where this is going).
Switching the include guard to make use of a property rather than a
variable took care of the problem nicely - w
On 4/4/16, Nicholas Braden wrote:
> I haven't tested this myself, but instead of using a glob, you could
> have a build step that generates a CMake script file with the list of
> generated files in it (e.g. via execute_process to run another CMake
> script whose only job is to generate the CMake s
Hello.
It seems that everyone defines their preprocessor symbols like this:
-DFOO
I actually prefer this:
-D FOO
(With a space.)
Is this just as portable as the version without the space though? Would
CMake remove the space if needed, and if not, would that ever cause issues?
--
Powe
14 matches
Mail list logo
