I am trying to set a flag for the Microsoft assembler, but no luck. Dummy
repro below.
I tried setting target_compile_options, but that seems not to work. Then I
tried setting CMAKE_ASM_MASM_FLAGS, but that does not seem to work either.
It seems like I am hitting this issue:
t a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 869c6dd..eb62f68 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
# CMake version number components.
set(CMake_VERSION_MAJOR 3)
set(CMake_VERSION_MINOR 13)
-set(CMake_VERSION_PATCH 20181121)
+set(CMake_VER
Hi Andreas,
> Am 21.11.2018 um 20:18 schrieb Andreas Naumann :
>
> I think the behavior is explained in [1] and [2]. In particular the second
> section of [2] states that the parameter " [...] such as ARGN are not
> variables in the usual CMake sense. They are string replacements [...]". And
Hey Torsten,
Am 21.11.18 um 13:15 schrieb Torsten Robitzki:
Hi,
I’ve stumbled over following behavior and now I’m searching for the rules, that
explains that behavior:
test.cmake:
macro(check_argn)
message("in macro check_argn ARGN: ${ARGN}")
if(ARGN)
foreach(item IN
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via 4e0c75b78f5745d1369867f25a46ab7d158b4469 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, release has been updated
via 8068850fcc1575210c968365e71cb7ece6771022 (commit)
via
Hi,
I’ve stumbled over following behavior and now I’m searching for the rules, that
explains that behavior:
test.cmake:
macro(check_argn)
message("in macro check_argn ARGN: ${ARGN}")
if(ARGN)
foreach(item IN LISTS ARGN)
message("ARG: ${item}")
endforeach(item)
Hi again,
Thanks David and Eric. I have actually used cmake’s pkgconfig integration to
support this library. As you say (about it not being very portable) I only
needed it on Linux so pkgconfig is a reasonable thing to use.
Thanks,
Harry
Harry Mallon
Senior Software Engineer
On 21/11/2018 09:46, David Demelier wrote:
> The philosophy behind CMake is to let upstream projects provides their
> own CMake configuration packages rather than providing Find modules for
> every single library existing in the world.
>
> CMake should already not provide any of these, but this
Le 21/11/2018 à 10:19, Jan Wielemaker a écrit :
Good. I was already considering providing a cmake file after migrating
SWI-Prolog to cmake. Are there good guidelines for this? Pkg-config asks
for providing a .pc file and installing in a well-known place. Is there
a similar place for project
Le mer. 21 nov. 2018 à 09:46, David Demelier a
écrit :
> Le 20/11/2018 à 17:03, Harry Mallon a écrit :
> > Hi,
> >
> > FindGTK and FindGTK2 exist in the CMake tree. How come there isn't one
> for GTK3? Should the GTK2 one work, or is there another way?
>
> GNOME people don't like CMake (they use
Le 20/11/2018 à 17:03, Harry Mallon a écrit :
Hi,
FindGTK and FindGTK2 exist in the CMake tree. How come there isn't one for
GTK3? Should the GTK2 one work, or is there another way?
GNOME people don't like CMake (they use meson). The philosophy behind
CMake is to let upstream projects
Le mar. 20 nov. 2018 à 22:40, Oleh Kravchenko a écrit :
> 20.11.18 23:29, Brad King wrote:
> > SOURCE_DATE_EPOCH was created for use by packagers where tools
> > already wrap the build. By making it an environment variable
> > packagers could jump through any number of build system layers
> >
13 matches
Mail list logo
