Re: [CMake] Problems Building a Java Project Under Cygwin
On 29/10/2017 04:44, R0b0t1 wrote: What fails is the compile step, like so: javac: file not found: \cygdrive\C\Users\R0b0t1\Documents\Code\project\build\CMakeFiles\project.dir\java_sources (The system cannot find the path specified) Is this due to a change in the path separator? On another note, are there any suggestions for building Java projects? Everything seems very confusing. I am not very smart. Respectfully, R0b0t1. the Java compiler is NOT a cygwin program, so it has no clue of \cygdrive. It will be more easy to use a windows cmake for your Java project -- 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] How to find dll's on Cygwin? (fwd)
On 28/10/2017 05:38, Alan W. Irwin wrote: On 2017-10-27 22:31+0200 Marco Atzeri wrote: On 27/10/2017 09:32, Alan W. Irwin wrote: Our understanding is the Cygwin naming convention for the various kinds of libraries would be (in the gnat library case) dll cyggnat-6.dll import library libgnat-6.dll.a static library libgnat.a Hi Alan, the understanding is correct, it should be libgnat-6.dll.a or libgnat.dll.a However as $ gnatlink -v -shared hello GNATLINK 6.4.0 Copyright (C) 1995-2016, Free Software Foundation, Inc. gcc -c -mtune=generic -march=x86-64 -gnatA -gnatWb -gnatiw -gnatws /tmp/ada/b~hello.adb /usr/bin/gcc.exe b~hello.o ./hello.o -shared -o hello.exe -L./ -L/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/ -lgnat-6 -Wl,--stack=0x200 -shared-libgcc /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lgnat-6 collect2: error: ld returned 1 exit status gnatlink: error when calling /usr/bin/gcc.exe I suspect the ada package is incomplete, so I raised the attention of the package maintainer. https://cygwin.com/ml/cygwin/2017-10/msg00358.html Regards Marco -- 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] How to find dll's on Cygwin? (fwd)
On 27/10/2017 09:32, Alan W. Irwin wrote: I am pretty sure there are a non-zero number of CMake users here who have had CMake experience finding dll's on Cygwin (since it appears from the quote below that import libraries can be replaced by dll's for the purposes of linking on that platform). So if you are one with such experience, I would really appreciate an answer to (or commment on) the specific question below concerning finding cyggnat-6.dll on Cygwin or if you prefer to frame your response to the more general question of finding dll's on that platform, that would be great as well. Alan using the import library is the standard way for linking, looking for the shared library is surely unusual. I am not a user of ADA, but the import libraries seems the one on /usr/lib/gcc/x86_64-pc-cygwin/6.4.0/adalib/ Marco -- 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] Post test in build tree
on latest Lapack source there is on "CTestCustom.cmake.in" the following command SET(CTEST_CUSTOM_POST_TEST "./lapack_testing.py -s -d TESTING") but unfortunately as "./lapack_testing.py" is on the source tree it does not work if the build tree is a different one. Any suggestion how to modify it ? Thanks in advance Marco -- 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] Problem compiling clang on cygwin, library prefix mismatch
On 19/09/2014 11:17, Guilherme wrote: The output i see on the command line is: make[2]: *** No rule to make target 'lib/libLLVMSupport.dll.a', needed by 'bin/cygLLVMLineEditor.dll'. Stop. Well i'm trying to build all as shared. on cygwin, the build system usually produce something like: $ find . -name "*dll*" ./cygqhull-6.dll ./cygqhull_p-6.dll ./libqhull.dll.a ./libqhull_p.dll.a the import library is called lib.dll.a while the shared is cygX.dll Regards Marco -- 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 3.0.1 - avast Win32;Dropper-gen
On 17/08/2014 14:30, Georgios Petasis wrote: Hi all, I installed the latest cmake under windows, and avast keeps telling me cmake.exe has a virus. The detected virus is Win32:Dropper-gen. Avast finds it in cmake.exe, inside both the windows zip file, and the setup file. Is it really a virus, or a false alarm? George I will bet on the second Marco -- 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] Cygwin drive paths are killing me
On 15/06/2014 23:45, J Decker wrote: Of course someone like me find some upsides, like having a large number of unix tools available on windows, otherwise we will have no users nor any packagers I guess over the years I've just ended up collecting small static versions of 'unix tools' in my tools folder under unix cp, rm, mv, ls, mkdir.exe, echo.exe, touch, uname, make.exe, and some less generally useful things, wget, ssh, cvs, mtn but I think of the above cmake only needs make and other things are handled with cmake -E commands and then the compiler... and make (mingw32-make) comes with mingw anyhow; so I'm pretty sure everything can build with MinGW (not MSYS), cmake, and the android NDK on a clean system. of course. I found curious on this "android NDK" the usage of a cygwin build system with a not cygwin compiler. I would expect of both or none, mixing is really complicating the things. Last time I cross compiled from windows to a Linux MIPS, the cross compiler was a true cygwin application. (and 30% faster than a cygwin environment) Likely, cygwin is handicapped by the lack of a true system fork. personally I can't stand how slow cygwin is; even things just built with cygwin run 30-50% slower than any other compiler... and it's really not worth it to have paths that don't really work and then redhat got ahold of it and it just went downhill from there (yes that was a long time ago) MinGW doesn't even need environment changes, just need the bin in PATH... cygwin also does not need environment changes. But this is more a discussion for another mailing list. Regards Marco -- 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] Cygwin drive paths are killing me
On 14/06/2014 21:31, Alan W. Irwin wrote: On 2014-06-14 12:25-0400 David Cole wrote: The difficulty of uninstalling it, and the difficulty of replicating a cygwin environment that is on one machine *exactly* on another machine with *all* the same components at *all* the same versions ... these are but 2 of the reasons I will NEVER rely on cygwin again for anything. It's just too painful, and there's absolutely NO upside. Hi Dave: Why are you holding back so much from giving us your real opinion of Cygwin? :-) Seriously though, I wonder if some of your complaints have an answer. About "difficulty of uninstalling" the answer is here: https://cygwin.com/faq.html#faq.setup.uninstall-all short version: - stop all cygwin programs - stop all the cygwin services - zap the cygwin directory Of course someone like me find some upsides, like having a large number of unix tools available on windows, otherwise we will have no users nor any packagers. Alan Marco PS: cmake works fine on cygwin, so thanks Dave. -- 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] Cygwin drive paths are killing me
On 11/06/2014 15:25, Eric Wing wrote: I am currently in this unholy trinity of needing to use Android on Windows through Cygwin. Basically, the Android NDK requires Cygwin if you want to run it on Windows. I'm using my fork of the Android-CMake toolchain originally from OpenCV and trying to generate "Unix Makefiles" with CMake. I provide a -C initial_cache list to try to pre-populate my dependency list since this is a cross-compile. This is really ugly stuff. I thought I was on the verge of finally getting it working, but I keep bouncing back and forth between file path problems: - Cygwin returns absolute paths like /cygdrive/c/Program Files (x86) - But CMake can't seem to resolve the /cygdrive/c part and when trying to access files in this form, it fails with 'file not found' Hi Eric, 1) don't use path with space in names. 2) cygwin version of CMAKE perfectly understand /cygdrive/c Thanks, Eric Regards Marco -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Status/use of CMake on Cygwin
Il 6/24/2013 12:04 AM, Hogan Jr, Roy E ha scritto:
Greetings,
I have been struggling to get the Trilinos solver package built using
Cmake, but have been unsuccessful so far. I have been working this for
several days and need help. I’m attaching a recent request to the
Trilinos mailing list. Would you have any guidance for me? Thank you..
Sincerely,
Roy Hogan
Hi Roy,
from you logs, I see that
mpiexec is found
mpifort is found
it is not clear if mpicc is not found or not recognized.
On my system
$ mpicc --version
gcc (GCC) 4.5.3
My suggestion:
-) check that openmpi is correctly installed
$ cygcheck -c openmpi libopenmpi-devel
Cygwin Package Information
Package VersionStatus
libopenmpi-devel 1.7.1-2OK
openmpi 1.7.1-2OK
-) check that mpicc is working, see attached test case.
$ mpicc hello_c.c -o hello_c
$ mpirun -n 4 ./hello_c.exe
Hello, world, I am 1 of 4
Hello, world, I am 2 of 4
Hello, world, I am 3 of 4
Hello, world, I am 0 of 4
Regards
Marco
/*
* Copyright (c) 2004-2006 The Trustees of Indiana University and Indiana
* University Research and Technology
* Corporation. All rights reserved.
* Copyright (c) 2006 Cisco Systems, Inc. All rights reserved.
*
* Sample MPI "hello world" application in C
*/
#include
#include "mpi.h"
int main(int argc, char* argv[])
{
int rank, size;
MPI_Init(&argc, &argv);
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
MPI_Comm_size(MPI_COMM_WORLD, &size);
printf("Hello, world, I am %d of %d\n", rank, size);
MPI_Finalize();
return 0;
}
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with "configured" file under Cygwin/Windows 7
Il 5/25/2013 1:06 PM, Arjen Markus ha scritto: Hello, I have installed a very recent version of Cygwin on Windows 7 (64 bits) and the version of CMake that comes with it (2.8.9-2). When I use this however to configure and build projects that work fine under Windows (various versions0, then I get either configuration problems or build problems that turn out to be caused by a strange permission set on "configured" files. Using one of these projects I have created an almost minimal project to demonstrate the problem. If you configure it via CMake under Windows 7, the file "gnulliver.h" has "special permissions". I have no clue what that means or how it arises, but the consequence is that a program can not open it. Not even a program running under Administrator rights. Oddly enough, you can change the permissions from Windows Explorer by opening the permissions dialogue and giving the user full access. I have tried to reproduce it in an even smaller project than the one attached, that is: just a CMakeListst.txt file and gnulliver.h.in, but that worked without this problem. So it seems a combination of steps is required to trigger this issue. Can anyone shed some light on this? It makes it impossible to use Cygwin in combination with Windows 7 (I have not tried on other platforms, quite possibly it is specific to this combination.) Regards, Arjen the attachment seems broken $ tar -xf problem-cygwin.tar tar: A lone zero block at 11 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Status/use of CMake on Cygwin
Il 5/20/2013 11:01 AM, Alan W. Irwin ha scritto: On 2013-05-20 07:51+0200 marco atzeri wrote: the slowness at startup on cywin is mainly due the fork implementation http://cygwin.com/faq/faq-nochunks.html#faq.api.fork unfortunately windows makes a real fork implementation very inefficient. Hi Marco: Your explanation sounds reasonable since it appears all new processes are started with fork, but do you have a reference for that conclusion that gives more specifics? All the above URL says is that fork can be "a little slow" on Cygwin with no timing specifics. "a littel slow" is an euphemism $ while (true); do date; done | uniq -c 11 Mon, May 20, 2013 11:38:10 AM 11 Mon, May 20, 2013 11:38:11 AM 11 Mon, May 20, 2013 11:38:12 AM 11 Mon, May 20, 2013 11:38:13 AM 11 Mon, May 20, 2013 11:38:14 AM 11 Mon, May 20, 2013 11:38:15 AM 8 Mon, May 20, 2013 11:38:16 AM 6 Mon, May 20, 2013 11:38:17 AM on Linux this is around 20-50 times faster. We also noted that Windows 64 bit platforms are slower than previously Windows 32 bit platforms see http://cygwin.com/ml/cygwin/2011-07/msg00354.html and similar on cygwin mailing list. Alan __ Alan W. Irwin Regards Marco -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Status/use of CMake on Cygwin
Il 5/20/2013 3:28 AM, Alan W. Irwin ha scritto: On 2013-05-19 21:06- David Cole wrote: With regard to your frustration with Cygwin speed, I must say I have similar frustrations with how fast commands execute under bash.exe. That issue appears to be entirely due to startup latency. For example, here is a comparison of "cmake --version" results on Linux versus running that same command under bash.exe on Wine. software@raven> time cmake --version cmake version 2.8.10.2 real0m0.008s user0m0.000s sys 0m0.004s bash.exe-3.1$ time cmake --version cmake version 2.8.10.2 real0m0.197s user0m0.000s sys 0m0.040s These results were determined with a CMake version I built myself on Linux and a downloaded Windows binary (built by Kitware with Microsoft proprietary compilers) on MinGW/MSYS/Wine, but in the past I have also gotten similar bad results for a CMake version that I built myself on MinGW/MSYS/Wine, and there are similar bad startup latency results (0.2 seconds just to execute the --version option for the command which is a factor of ~25 slower than the corresponding Linux result) for all other heavily used build commands such as gcc and make. So this is a general bash.exe issue and not a cmake issue, and it a real killer of build speeds since cmake and gcc are often invoked during the build process (e.g., to provide progress reports, to make a quick build test, or to actually make a build containing many separate small source files ) in a way that is completely dominated by the bad startup latency numbers above. At this point I don't know whether this startup latency issue is due to an issue with bash.exe on Wine or a more general bash.exe issue on Windows, and if anybody hear could do such a simple "time cmake --version" test for a MSYS/bash.exe environment on Microsoft Windows to see whether the result is nearer 0.200 seconds or 25 times faster that might confirm or eliminate Wine as the culprit. the slowness at startup on cywin is mainly due the fork implementation http://cygwin.com/faq/faq-nochunks.html#faq.api.fork unfortunately windows makes a real fork implementation very inefficient. Alan __ Alan W. Irwin Marco -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cygwin Boost find error
On 4/25/2013 10:07 AM, Lloyd wrote: Thanks the link helped me to solved the problem. Sorry, I shall avoid irrelevant posts in the future It is not irrelevant, but you have more chance to have the right answer on the cygwin help list. Regards Marco -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cygwin Boost find error
On 4/25/2013 8:54 AM, Lloyd wrote: Hi, I am building a project in both Windows 7 and Cygwin. I am using boost libraries in the project and it works correctly in windows FIND_PACKAGE(Boost REQUIRED COMPONENTS unit_test_framework) When I try to configure in cygwin it returns error saying that could not find boost. From Cygwin installer i have installed boost (both source as well as the library version). Still cmake could not find it. I also tried to locate the library, but could not find it. Can you please tell me the default location of boost in cygwin? or is there a way to locate the install paths of libraries? this is more a question for cygwin help list, anyway the development headers and libraries location are reported here: http://cygwin.com/packages/libboost-devel/libboost-devel-1.50.0-1 I think it is not possible to use the Windows version of boost with cygwin as I am using different compilers (Visual studio in windows and gcc in cygwin). correct. gcc4 package for cygwin Thanks, Lloyd -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin at 64bit
On 3/15/2013 5:14 PM, marco atzeri wrote: On 3/15/2013 4:41 PM, Bill Hoffman wrote: On 3/15/2013 11:31 AM, marco atzeri wrote: ok, found. I do not need to malloc the space for the win32_path assigning again the pointer does not work. Next step, to check if no other issues on 64bit Yes, that would do it... If you allocate new memory then the information never gets passed back to the caller... :) -Bill copy and past code, sometimes, does not work. attached the patch to remove cygwin_conv_to_win32_path. First bootstrap on cygwin64 works, still running the rest of the build. Marco Hi Bill, my trial builds but does not pass all tests and fails on source packaging ; I guess for a mismatch in path length capability between the two solutions. The solution implemented by Yaakov, to completely remove the path conversion posix/win32 as reported on http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/cmake;a=tree works on both 32bit and 64bit cygwin platform Regards Marco -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin at 64bit
On 3/15/2013 4:41 PM, Bill Hoffman wrote:
On 3/15/2013 11:31 AM, marco atzeri wrote:
ok, found.
I do not need to malloc the space for the win32_path
assigning again the pointer does not work.
Next step, to check if no other issues on 64bit
Yes, that would do it... If you allocate new memory then the
information never gets passed back to the caller... :)
-Bill
copy and past code, sometimes, does not work.
attached the patch to remove cygwin_conv_to_win32_path.
First bootstrap on cygwin64 works,
still running the rest of the build.
Marco
--- ../orig/cmake-2.8.9/Source/kwsys/SystemTools.cxx2012-08-15
21:28:03.0 +0200
+++ cmake-2.8.9/Source/kwsys/SystemTools.cxx2013-03-15 16:56:12.540496600
+0100
@@ -85,7 +85,21 @@
#endif
#ifdef __CYGWIN__
-extern "C" void cygwin_conv_to_win32_path(const char *path, char *win32_path);
+typedef unsigned int cygwin_conv_path_t;
+enum
+{
+ CCP_POSIX_TO_WIN_A = 0, /* from is char*, to is char* */
+ CCP_POSIX_TO_WIN_W, /* from is char*, to is wchar_t**/
+ CCP_WIN_A_TO_POSIX, /* from is char*, to is char* */
+ CCP_WIN_W_TO_POSIX, /* from is wchar_t*, to is char**/
+
+ CCP_CONVTYPE_MASK = 3,
+
+ /* Or these values to the above as needed. */
+ CCP_ABSOLUTE = 0, /* Request absolute path (default). */
+ CCP_RELATIVE = 0x100/* Request to keep path relative. */
+};
+extern "C" ssize_t cygwin_conv_path( cygwin_conv_path_t what, const void *
from, void * to, size_t size );
#endif
// getpwnam doesn't exist on Windows and Cray Xt3/Catamount
@@ -1123,7 +1137,15 @@
}
else
{
-cygwin_conv_to_win32_path(path, win32_path);
+ssize_t size;
+size=cygwin_conv_path(CCP_POSIX_TO_WIN_A, path, NULL, 0 );
+if (size < 0)
+ perror ("cygwin_conv_path");
+else
+ {
+if (cygwin_conv_path(CCP_POSIX_TO_WIN_A, path, win32_path, size ))
+ perror ("cygwin_conv_path");
+ }
SystemToolsTranslationMap::value_type entry(path, win32_path);
SystemTools::Cyg2Win32Map->insert(entry);
}
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin at 64bit
On 3/15/2013 4:00 PM, marco atzeri wrote: On 3/15/2013 3:24 PM, Bill Hoffman wrote: On 3/15/2013 7:17 AM, marco atzeri wrote: Dear Bill, we are starting to port packages on cygwin at 64 bit http://cygwin.com/ml/cygwin-apps/2013-03/msg00070.html Of course a cmake version for that platform will be helpful; I tried to build the current source and the first obstacle is that the deprecated "cygwin_conv_to_win32_path" function is not available anymore. I tried to replace it with "cygwin_conv_path" but it seems I am missing something as on both 64 and 32 bit versions the outcome is: Have you tried adding the print statements to the original code and building with 32 bit cygwin and comparing results? good idea, unfortunately they look the same posix /pub/devel/cmake/cmake-2.8.9/.build/Bootstrap.cmk/cmake.com win32 E:\cygwin\pub\devel\cmake\cmake-2.8.9\.build\Bootstrap.cmk\cmake.com posix /pub/devel/cmake/cmake-2.8.9/.build/Bootstrap.cmk/cmake.exe win32 E:\cygwin\pub\devel\cmake\cmake-2.8.9\.build\Bootstrap.cmk\cmake.exe except that of course it works. I will try to avoid including all the cygwin.h, could be that I am modifying something I should not ok, found. I do not need to malloc the space for the win32_path assigning again the pointer does not work. Next step, to check if no other issues on 64bit Regards Marco Marco -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin at 64bit
On 3/15/2013 3:24 PM, Bill Hoffman wrote: On 3/15/2013 7:17 AM, marco atzeri wrote: Dear Bill, we are starting to port packages on cygwin at 64 bit http://cygwin.com/ml/cygwin-apps/2013-03/msg00070.html Of course a cmake version for that platform will be helpful; I tried to build the current source and the first obstacle is that the deprecated "cygwin_conv_to_win32_path" function is not available anymore. I tried to replace it with "cygwin_conv_path" but it seems I am missing something as on both 64 and 32 bit versions the outcome is: Have you tried adding the print statements to the original code and building with 32 bit cygwin and comparing results? good idea, unfortunately they look the same posix /pub/devel/cmake/cmake-2.8.9/.build/Bootstrap.cmk/cmake.com win32 E:\cygwin\pub\devel\cmake\cmake-2.8.9\.build\Bootstrap.cmk\cmake.com posix /pub/devel/cmake/cmake-2.8.9/.build/Bootstrap.cmk/cmake.exe win32 E:\cygwin\pub\devel\cmake\cmake-2.8.9\.build\Bootstrap.cmk\cmake.exe except that of course it works. I will try to avoid including all the cygwin.h, could be that I am modifying something I should not CMake Error: CMake executable cannot be found at /cmake.exe CMake Error: Error executing cmake::LoadCache(). Aborting. I added two printf, to check my changes; the conversion seems right -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake for cygwin at 64bit
Dear Bill,
we are starting to port packages on cygwin at 64 bit
http://cygwin.com/ml/cygwin-apps/2013-03/msg00070.html
Of course a cmake version for that platform will be helpful;
I tried to build the current source and the first obstacle is that
the deprecated "cygwin_conv_to_win32_path" function is not
available anymore.
I tried to replace it with "cygwin_conv_path" but it seems I am missing
something as on both 64 and 32 bit versions the outcome is:
CMake Error: CMake executable cannot be found at /cmake.exe
CMake Error: Error executing cmake::LoadCache(). Aborting.
I added two printf, to check my changes;
the conversion seems right
posix path /pub/devel/cmake/cmake-2.8.9/.build/Bootstrap.cmk/cmake.com
win32 path
E:\cygwin\pub\devel\cmake\cmake-2.8.9\.build\Bootstrap.cmk\cmake.com
posix path /pub/devel/cmake/cmake-2.8.9/.build/Bootstrap.cmk/cmake.exe
win32 path
E:\cygwin\pub\devel\cmake\cmake-2.8.9\.build\Bootstrap.cmk\cmake.exe
posix path /pub/devel/cmake/cmake-2.8.9/.build/Bootstrap.cmk/cmake
win32 path
E:\cygwin\pub\devel\cmake\cmake-2.8.9\.build\Bootstrap.cmk\cmake
file is there
$ ls -l /pub/devel/cmake/cmake-2.8.9/.build/Bootstrap.cmk/cmake.exe
-rwxr-xr-x 1 marco Administrators 5733380 Mar 15 09:34
/pub/devel/cmake/cmake-2.8.9/.build/Bootstrap.cmk/cmake.exe
and it is a working binary, as direct execution gives :
$ /pub/devel/cmake/cmake-2.8.9/.build/Bootstrap.cmk/cmake.exe
Bootstrap CMake should not be used outside CMake build process.
So I am clearly missing something else .
Any idea ?
Marco
--- orig/cmake-2.8.9/Source/kwsys/SystemTools.cxx 2012-08-15
21:28:03.0 +0200
+++ cmake-2.8.9/Source/kwsys/SystemTools.cxx2013-03-15 09:33:39.928041000
+0100
@@ -85,7 +85,8 @@
#endif
#ifdef __CYGWIN__
-extern "C" void cygwin_conv_to_win32_path(const char *path, char *win32_path);
+#include
+extern "C" ssize_t cygwin_conv_path( cygwin_conv_path_t what, const void *
from, void * to, size_t size );
#endif
// getpwnam doesn't exist on Windows and Cray Xt3/Catamount
@@ -1123,7 +1124,20 @@
}
else
{
-cygwin_conv_to_win32_path(path, win32_path);
+ssize_t size;
+size=cygwin_conv_path(CCP_POSIX_TO_WIN_A, path, NULL, 0 );
+if (size < 0)
+ perror ("cygwin_conv_path");
+else
+ {
+win32_path= (char *) malloc (size);
+if (cygwin_conv_path(CCP_POSIX_TO_WIN_A, path, win32_path, size ))
+ perror ("cygwin_conv_path");
+ }
+
+printf(" posix path %s\n", path);
+printf(" win32 path %s\n", win32_path);
+
SystemToolsTranslationMap::value_type entry(path, win32_path);
SystemTools::Cyg2Win32Map->insert(entry);
}
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake-2.8.7 crash on cygwin
On 8/8/2012 10:48 PM, marco atzeri wrote:
Hi,
trying to build vtk-5.10.0-1 with cygwin cmake-2.8.7,
cmake crashes building vtkUnicodeCaseFoldData.h
$ cmake -P vtkUnicodeString.cmake
Aborted (core dumped)
leaving an almost empty
$ cat vtkUnicodeCaseFoldData.h
// Generated file, do not edit by hand!
static vtkUnicodeString::value_type vtkUnicodeCaseFoldData[] = {
-
cmake crash on cygwin-1.7.15 , 1.7.16 and latest snapshot
so it could be a cmake bug.
If someone want to test or investigate, I uploaded files, strace
and stackdump on
http://matzeri.altervista.org/works/cmake/
Regards
Marco
using cmake-2.8.8-2 from
http://sourceware.org/cygwinports/
I have no crash, so or it is a bug solved in 2.8.8
or attached Yaakov's patch solve the issue.
Bill,
could you look on it for the next 2.8.9 cygwin package ?
Regards
Marco
--- origsrc/cmake-2.8.8/Source/kwsys/SystemTools.cxx2012-04-18
13:10:54.0 -0500
+++ src/cmake-2.8.8/Source/kwsys/SystemTools.cxx2012-07-11
05:42:36.768957300 -0500
@@ -73,13 +73,6 @@
// Windows API.
#if defined(_WIN32)
# include
-#elif defined (__CYGWIN__)
-# include
-# undef _WIN32
-#endif
-
-#ifdef __CYGWIN__
-extern "C" void cygwin_conv_to_win32_path(const char *path, char *win32_path);
#endif
// getpwnam doesn't exist on Windows and Cray Xt3/Catamount
@@ -876,7 +869,7 @@ bool SystemTools::SameFile(const char* f
}
//
-#if defined(_WIN32) || defined(__CYGWIN__)
+#if defined(_WIN32)
static bool WindowsFileExists(const char* filename)
{
WIN32_FILE_ATTRIBUTE_DATA fd;
@@ -891,15 +884,7 @@ bool SystemTools::FileExists(const char*
{
return false;
}
-#if defined(__CYGWIN__)
- // Convert filename to native windows path if possible.
- char winpath[MAX_PATH];
- if(SystemTools::PathCygwinToWin32(filename, winpath))
-{
-return WindowsFileExists(winpath);
-}
- return access(filename, R_OK) == 0;
-#elif defined(_WIN32)
+#if defined(_WIN32)
return WindowsFileExists(filename);
#else
return access(filename, R_OK) == 0;
@@ -919,26 +904,6 @@ bool SystemTools::FileExists(const char*
}
//
-#ifdef __CYGWIN__
-bool SystemTools::PathCygwinToWin32(const char *path, char *win32_path)
-{
- SystemToolsTranslationMap::iterator i =
-SystemTools::Cyg2Win32Map->find(path);
-
- if (i != SystemTools::Cyg2Win32Map->end())
-{
-strncpy(win32_path, i->second.c_str(), MAX_PATH);
-}
- else
-{
-cygwin_conv_to_win32_path(path, win32_path);
-SystemToolsTranslationMap::value_type entry(path, win32_path);
-SystemTools::Cyg2Win32Map->insert(entry);
-}
- return win32_path[0] != 0;
-}
-#endif
-
bool SystemTools::Touch(const char* filename, bool create)
{
if(create && !SystemTools::FileExists(filename))
@@ -3702,7 +3667,7 @@ bool SystemTools::LocateFileInDir(const
bool SystemTools::FileIsFullPath(const char* in_name)
{
kwsys_stl::string name = in_name;
-#if defined(_WIN32) || defined(__CYGWIN__)
+#if defined(_WIN32)
// On Windows, the name must be at least two characters long.
if(name.length() < 2)
{
@@ -4520,9 +4485,6 @@ bool SystemTools::ParseURL( const kwsys_
unsigned int SystemToolsManagerCount;
SystemToolsTranslationMap *SystemTools::TranslationMap;
SystemToolsTranslationMap *SystemTools::LongPathMap;
-#ifdef __CYGWIN__
-SystemToolsTranslationMap *SystemTools::Cyg2Win32Map;
-#endif
// SystemToolsManager manages the SystemTools singleton.
// SystemToolsManager should be included in any translation unit
@@ -4568,9 +4530,6 @@ void SystemTools::ClassInitialize()
// Allocate the translation map first.
SystemTools::TranslationMap = new SystemToolsTranslationMap;
SystemTools::LongPathMap = new SystemToolsTranslationMap;
-#ifdef __CYGWIN__
- SystemTools::Cyg2Win32Map = new SystemToolsTranslationMap;
-#endif
// Add some special translation paths for unix. These are not added
// for windows because drive letters need to be maintained. Also,
@@ -4625,9 +4584,6 @@ void SystemTools::ClassFinalize()
{
delete SystemTools::TranslationMap;
delete SystemTools::LongPathMap;
-#ifdef __CYGWIN__
- delete SystemTools::Cyg2Win32Map;
-#endif
}
--- origsrc/cmake-2.8.8/Source/kwsys/SystemTools.hxx.in 2012-04-18
13:10:54.0 -0500
+++ src/cmake-2.8.8/Source/kwsys/SystemTools.hxx.in 2012-07-11
17:42:52.097828100 -0500
@@ -277,15 +277,6 @@ public:
static bool FileExists(const char* filename);
/**
- * Converts Cygwin path to Win32 path. Uses dictionary container for
- * caching and calls to cygwin_conv_to_win32_path from Cygwin dll
- * for actual translation. Returns true on success, else false.
- */
-#ifdef __CYGWIN__
- static bool PathCygwinToWin32(const char *path, char *win32_path)
[CMake] cmake-2.8.7 crash on cygwin
Hi,
trying to build vtk-5.10.0-1 with cygwin cmake-2.8.7,
cmake crashes building vtkUnicodeCaseFoldData.h
$ cmake -P vtkUnicodeString.cmake
Aborted (core dumped)
leaving an almost empty
$ cat vtkUnicodeCaseFoldData.h
// Generated file, do not edit by hand!
static vtkUnicodeString::value_type vtkUnicodeCaseFoldData[] = {
-
cmake crash on cygwin-1.7.15 , 1.7.16 and latest snapshot
so it could be a cmake bug.
If someone want to test or investigate, I uploaded files, strace
and stackdump on
http://matzeri.altervista.org/works/cmake/
Regards
Marco
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] A way to suppress 'make install' output
On 6/25/2012 10:50 AM, Michele Santullo wrote: On 06/25/2012 10:42 AM, marco atzeri wrote: On 6/25/2012 10:29 AM, Stefan Eilemann wrote: Hi, I'm looking for a way to suppress the output when installing a project: One of our projects installs a large directory structure, and the resulting 'make install' output is so noisy that finding other errors in parallel builds is next to impossible. Does somebody have an idea? Cheers, Stefan. make install &> filename no output at all and everything in the "filename" -- Suppressing would be more like redirecting to /dev/null. Use just > to keep eventual messages on stderr. mic my solution saved the output. /dev/null is not very verbose ;-) In general a good learning point is http://tldp.org/LDP/abs/html/io-redirection.html My preference will be to save all the log on different files and to not suppress anything make |& tee make_build.log make install |& tee make_install.log It is a personal taste of course Regards Marco -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] A way to suppress 'make install' output
On 6/25/2012 10:29 AM, Stefan Eilemann wrote: Hi, I'm looking for a way to suppress the output when installing a project: One of our projects installs a large directory structure, and the resulting 'make install' output is so noisy that finding other errors in parallel builds is next to impossible. Does somebody have an idea? Cheers, Stefan. make install &> filename no output at all and everything in the "filename" -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Where can I get the latest version of CMake for cygwin?
On 3/2/2012 8:55 PM, Bill Hoffman wrote: On 3/2/2012 1:57 PM, Robert Dailey wrote: Latest version of CMake on the Cygwin installer is 2.8.4. I need 2.8.7. Where can I get 2.8.7 for Cygwin? We have them built, but I have been very bad at not getting them uploaded to the server. You can find them here: http://www.cmake.org/files/v2.8/cmake-2.8.7-1.tar.bz2 Bill, a simple RFU (request for upload) at cygwin-apps mailing list, with the link at your files http://www.cmake.org/files/v2.8/cmake-2.8.7-1.tar.bz2 http://www.cmake.org/files/v2.8/cmake-2.8.7-1-src.tar.bz2 will allow a larger audience and the correct deployment of your package. Thank in advance Marco -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake for cygwin
Hi Bill, any plan to update the cygwin package ? Currently we are still on 2.8.4-1 Regards Marco -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake package for cygwin
Hi Bill, are you planning to release the 2.8.4 package for cygwin ? Thanks in advance Marco ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FIND_PROGRAM w/ CMake 2.8.2 and Cygwin
On Mon, Jan 10, 2011 at 6:55 PM, Emmanuel Blot wrote:
> On Mon, Jan 10, 2011 at 5:56 PM, marco atzeri wrote:
>> I don't understand why you find and empty definition
>
> Well, it seems that CYGWIN is not defined:
>
> MESSAGE (STATUS "CYGWIN: ${CYGWIN}")
> MESSAGE (STATUS "Suffix: ${CMAKE_EXECUTABLE_SUFFIX}")
> FIND_PROGRAM (xcc1 ${XTOOLCHAIN}-gcc-${XCC_VER})
> MESSAGE (STATUS "XCC1 evaluates to ${xcc1}")
> SET (CMAKE_EXECUTABLE_SUFFIX ".exe")
> MESSAGE (STATUS "Suffix: ${CMAKE_EXECUTABLE_SUFFIX}")
> FIND_PROGRAM (xcc2 ${XTOOLCHAIN}-gcc-${XCC_VER})
> MESSAGE (STATUS "XCC2 evaluates to ${xcc2}")
> FIND_PROGRAM (xcc3 ${XTOOLCHAIN}-gcc-${XCC_VER}.exe)
> MESSAGE (STATUS "XCC3 evaluates to ${xcc3}")
>
> gives:
>
> -- CYGWIN:
> -- Suffix:
> -- XCC1 evaluates to xcc1-NOTFOUND
> -- Suffix: .exe
> -- XCC2 evaluates to xcc2-NOTFOUND
> -- XCC3 evaluates to /usr/local/gnu-eabi-4.5.2/bin/arm-eabi-gcc-4.5.2.exe
>
> Forcing CMAKE_EXECUTABLE_SUFFIX does not help either.
>
> Is there some special invokation to perform so that CYGWIN gets detected?
> Maybe some cross-compilation setting invalidates the CYGWIN detection?
>
> Cheers,
> Manu
>
Manu,
please maintain the discussion on the mailing list as these is a general issue
if you are cross compiling, the target is not cygwin, so CYGWIN is not defined.
However on cygwin both
arm-eabi-gcc-4.5.2.exe
arm-eabi-gcc-4.5.2
are valid program names and you can call them.
I am not familiar with cmake and cross compiling, so I can help you on
the specific matter.
Marco
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FIND_PROGRAM w/ CMake 2.8.2 and Cygwin
On Mon, Jan 10, 2011 at 3:43 PM, Emmanuel Blot wrote: > Hello All, > > I've just bumped into an issue with Cygwin. > > I have not compiled with CMake and Cygwin for a while, so I'm not sure > where the problem comes from (Cygwin, CMake, or the combination of > both). > > The following command used to work on all platforms (Linux, Mac OS X, Cygwin): > FIND_PROGRAM (xcc arm-eabi-gcc) > but now, with Cygwin, the command fails to locate the executable which > is in the path indeed. > > IF I had the Windows executable suffix (.exe), it works: > FIND_PROGRAM (xcc arm-eabi-gcc.exe) > Obviously, the "fix" is not portable and will break on any non-Windows > platform. > > Some questions: > > 1/ Is this a known issue / new regression? > I have not been subscribed to the ML for a while, and I can't find a > decent way to search through the ML archives, > http://www.cmake.org/pipermail/cmake/ does not offer a search use gmane for the search http://news.gmane.org/gmane.comp.programming.tools.cmake.user > function. Sorry if the question has already been answered (let me know > if it is) > 2/ What is the best way to circumvent this issue? > 3/ Am I missing something obvious? > > Note: "CMAKE_EXECUTABLE_SUFFIX" is defined to the empty string on > CMake 2.8.2/Cygwin, which seems wrong as well. > > Cheers, > Manu in the past Yaakov proposed several changes for cygwin and SET(CMAKE_EXECUTABLE_SUFFIX ".exe") is present in its proposal. http://public.kitware.com/Bug/view.php?id=10122 I presume next 2.8.4 will cover it Marco ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] R: CMake 2.8.4 release scheduled for next month
--- Gio 9/12/10, David Cole ha scritto: > (copying a CMake developers email to > the users list, just as an FYI to > all the CMake users out here...) > > The CMake developers held a "bug triage" meeting yesterday, > and here > are some notes about it: > > We are still planning to start the release candidate cycle > for CMake > 2.8.4 on Wed. Jan. 12, 2011. Because of that, all changes > to be > considered for inclusion in the -rc1 build should be pushed > to the > stage and merged to 'next' before the nightly start time on > the > evening of Mon. Jan. 10, 2011. > > Assuming changes are in by that time, and they all pass the > 'Nightly > Expected' dashboard the next day, Brad and I will merge > them into > 'master' on Tues. Jan. 11. Then, we'll be ready to build > the rc1 on > Wed., assuming nothing alarming in the 'Nightly 2.8 > Release' dashboard > section. > > After that point, we will not accept further changes for > CMake 2.8.4 > except for fixes for regressions and crashes. > > Closed: > = > We closed these because they are fixed long ago, they no > longer apply, > or we're just never going to do them: > http://public.kitware.com/Bug/view.php?id=861 > http://public.kitware.com/Bug/view.php?id=1048 > http://public.kitware.com/Bug/view.php?id=1053 > http://public.kitware.com/Bug/view.php?id=1063 > http://public.kitware.com/Bug/view.php?id=1103 > http://public.kitware.com/Bug/view.php?id=9968 > > Deferrals: > = > We decided to defer the following bugs to a future release > because > there is not enough time left to complete them before the > scheduled > date: > http://public.kitware.com/Bug/view.php?id=115 > http://public.kitware.com/Bug/view.php?id=8396 > http://public.kitware.com/Bug/view.php?id=11445 > > Still in progress: > = > The remainder of the bugs that are still targeted for > potential > inclusion in 2.8.4 are listed on the roadmap: > http://public.kitware.com/Bug/roadmap_page.php > > > Thanks to all who slogged through the bug list with us > yesterday. > Looking forward to a solid 2.8.4 release first thing in > 2011! > > > Cheers, > David any hope to solve http://public.kitware.com/Bug/view.php?id=10122 with the discussed change of policy for cygwin ? Regards Marco ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake policy setting
As there is no example in the documentaion, could someone clarify me if the change of any policy that should require an additional cmake_policy(SET CMP NEW) could also be requested at cmake invocation with --- # -D :=: Create a cmake cache entry. When cmake is first run in an empty build tree, it creates a CMakeCache.txt file and populates it with customizable settings for the project. This option may be used to specify a setting that takes priority over the project's default value. The option may be repeated for as many cache entries as desired. --- Regards Marco ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin
--- Gio 28/10/10, Marcus D. Hanwell ha scritto: > It seems that the policy based approach would have allowed > you a one > line patch to most packages (changing the policy to NEW). I guess so. I can work with a one single line patch. > Marcus Marco ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin
--- Mer 27/10/10, Marcus D. Hanwell ha scritto: > On Wed, Oct 27, 2010 at 2:38 PM, Alan > W. Irwin > wrote: > > On 2010-10-26 17:53-0400 Bill Hoffman wrote: > > > >> The policy mechanism might not be ideal but in a > year or so, all of this > >> would go away, and the meantime the patches you > have to maintain for cygwin > >> ports would become trivial. The patch would > basically have a set cmake > >> version at the top. I thought the command line > option was a nice > >> compromise. > > > > Bill, as somebody associated with a software package > (PLplot) which > > already works on Cygwin, I think the policy mechanism > is the ideal way > > to handle this requested change. I do believe the > Cygwin packagers > > when they say the change will make a lot more projects > build without > > issues on Cygwin, but it is also extremely likely > their preferred > > solution (breaking backwards compatibility for cmake) > would also break > > currently working builds (such as the PLplot one) on > Cygwin. > > > > I sympathize with the frustrations of the Cygwin > packagers at the > > slowness with which this issue has been dealt with, > but OTOH, I am not > > sure they completely understand the neat resolution of > the issue that > > you are now offering with a policy-based approach to > the requested > > change. Thus, I suggest you just go ahead and > implement that preferred > > solution without further frustrating delays. Then > publish cookbook > > instructions about the one-line change that needs to > be made in the > > top-level CMakeLists.txt file of each currently > non-working Cygwin > > project (but not the working ones like PLplot) in > order for the new > > policy to be recognized. Ideally, upstream projects > that currently > > don't build on Cygwin will adopt this solution, but if > they are slow > > in doing that, it should not be too difficult for the > Cygwin packagers > > to implement a sed (or whatever) script to do the > required one-line > > changes in the top-level CMakeLists.txt files for each > package in an > > automatic fashion. > > As someone who packaged software for Gentoo Linux for many > years I can > sympathize with your frustration when something is not > corrected in a > timely fashion. I don't know much about the background of > this > particular case, but I would hope that you would choose to > work with > Bill rather than patch CMake and circumvent his efforts to > fix this > issue. > > If this results in a one line patch to Cygwin packages in > the short > term, which can be removed in the longer term, that would > seem like a > reasonable solution to the problem. Breaking backwards > compatibility > could potentially break all of the packages people got > working on > Cygwin with CMake, and that would be far worse. > > Disclaimer: I am also a Kitware employee, but before I came > here I > worked in open source for many years as part of larger > projects such > as Gentoo, KDE and Avogadro. I for one like the policy > mechanism, as > it allows CMake to move forward while not breaking existing > builds. As > a packager I would never intentionally change the default > behavior of > a project, effectively forking the project. > > If you chose to take such rash action I would also avoid > cygwin in the future. > > Marcus Hi Marcus, I guess your comments were for me and not really for Irwin. Unfortunately in this case the policy chosen for CYGWIN is a BAD one, causing most of package not originally designed with cygwin in mind (and I should say they are the vast majority) to be almost impossible to correctly port on Cygwin without a deep and invasive patch activity. My and Yaakov's experience is that inverting the policy the porting becomes very easy and almost all the package build from the source without patches or few very basic changes. I hope this also clarify you and the others why we are so "obsessive" about this change. I prefer this change in cmake than starting a "don Quixote" quest to change all the softwares that use cmake as build system. Regards Marco Disclaimer: I am just a volunteer cygwin package maintainer, my job is totally unrelated to this activity. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin
--- Mer 27/10/10, Alan W. Irwin ha scritto: > On 2010-10-26 17:53-0400 Bill Hoffman > wrote: > > > The policy mechanism might not be ideal but in a year > or so, all of this would go away, and the meantime the > patches you have to maintain for cygwin ports would become > trivial. The patch would basically have a set cmake > version at the top. I thought the command > line option was a nice compromise. > > Bill, as somebody associated with a software package > (PLplot) which > already works on Cygwin, I think the policy mechanism is > the ideal way > to handle this requested change. I do believe the > Cygwin packagers > when they say the change will make a lot more projects > build without > issues on Cygwin, but it is also extremely likely their > preferred > solution (breaking backwards compatibility for cmake) would > also break > currently working builds (such as the PLplot one) on > Cygwin. [cut] > > Alan Hi Irwin, thanks for the feedback. PLplot seems a interesting piece of software, and I noticed it needs/looks qhull and octave, of whom I am the cygwin package maintainer. Excluding the tcl/tk requirement, whose package need deep maintenance on cygwin, PLplot build fine with WIN32=0. With just some quirk behaviour building the modules (*.rc), but it could be a interference of my antivirus There is a general test mode ? Or I should run one by one test-drv-info" test_cairo_dyndriver" test_dyndrivers" test_mem_dyndriver" test_null_dyndriver" test_ps_dyndriver" test_svg_dyndriver" test_xfig_dyndriver" test_xwin_dyndriver" Regards Marco ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin
--- Mer 27/10/10, Clinton Stimpson ha scritto: > I did see in the Cygwin overview that the Win32 api should > generally be > avoided. > > However, its probably misleading that chapter 4, > "Programming with Cygwin," > shows Win32 code instead of Unix code in the examples. > http://cygwin.com/cygwin-ug-net/programming.html Updating the documentation is always THE problem ;-) But sometimes also on cygwin you need to develop something that is windows aware like a console http://code.google.com/p/mintty/ > > Clint > Marco ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin
--- Mer 27/10/10, Alexander Neundorf ha scritto: > > >> I suppose one other options is something like > this: > > >> > > >> "Warning: CMake has be forced to break > backwards > > >> compatibility by the cygwin ports > maintainers, we apologize > > >> if this broke your code. If your code does > not compile, then > > >> set the cygwin policy to OLD, or add > if(CYGWIN) set(WIN32 1) > > >> to your code." > > > > > > I am not familiar with the cmake policy stuff. > > > But it seems a workable solution. > > > > In my, not so humble, opinion it is the only solution > if you insist on > > changed behavior. > > I agree too. > As a cmake developer, keeping backward compatibility is one > of the major goals > of cmake. > Just changing the behaviour will most probably break stuff > which is working > now. > Who uses cmake for building for cygwin, can test for > if(UNIX) > or > if(CYGWIN) > > To differentiate between CYGWIN and a "real" native UNIX he > can also test for > if(WIN32), e.g. to check whether some other Windows stuff > exists on the > system (which does). > This seems like a good and sensible choice to me. > > If a cmake-based project wants to support cygwin, it must > be aware of that. > If a project which was developed on e.g. Linux is ported to > Cygwin, some > patches may be necessary to that program. I think that's > normal when porting > software to another OS. > > Alex Dear Alex, thanks for you comments, but I would like to highlight one missing point on your reasoning. We don't want to limit ourself to the packages where the developer thought of cygwin as a defined target, we are potentially interested to all packages that have a generic unix as target. Most of the projects ignore what cygwin is; their developers write CMakeLists.txt with IF(WIN32) conditions for windows and IF(UNIX) for unix. Trying to build such programs on cygwin with both the two conditions is doomed to failure. To port such package, that are by large the majority, on cygwin we have 3 options: 1) propose a long patch to every upstream, highlighting the mistake they did forgetting us. Considering the easy success we have to convince cmake developers, this road is more a less a nightmare for any cygwin package maintainers. 2) use a cmake package outside the cygwin distro that don't set WIN32 for cygwin. It is my current solution; but it is not optimal for cygwin as I would like that also others could build the packages as I am doing. Should every cygwin maintainer have its own cmake package ? 3) convince the current cmake cygwin package maintainer, that is also a cmake developer, that we need a way to unset WIN32. How ? I am open to proposal, except case 1, please. I understand that making a unconditional WIN32 switch could break some package, but I suspect they are much less than Bill is afraid of. After all I built both CMAKE and VTK with WIN32=0. But I admit that eventually my build is different from the original aim of their developers. Having a switch/policy to define the cygwin behaviour, is a possible solution that would allow us to build the majority of unix package as smooth as possible also for cygwin and allow current developers using cmake on cygwin to maintain their settings if they need so. Regards Marco ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin
--- Mer 27/10/10, Bill Hoffman ha scritto: > On 10/26/2010 9:58 PM, Yaakov > (Cygwin/X) wrote: > > On Tue, 2010-10-26 at 17:53 -0400, Bill Hoffman > wrote: > >> Backwards compatibility may not be important to > you, but to CMake it is > >> very important. When a developer chooses to > use CMake, I want to > >> respect that choice, and work as hard as I can to > make sure I don't > >> break that code. CMake has been > doing this for 10 years on cygwin, > >> wrong or right that is how it has been > done. If there is code that > >> builds with CMake on cygwin today, your suggested > change will break that > >> build. > > > > No, it will most likely *fix* it. > How is that possible? If it is working today with the > way CMake is for someone, and we make this change, it will > stop working. It can not *fix* something that is > already working. It can only break something that is > already working, it can not fix something not broken... Bill, it is not working. We don't succeed to port programs using cmake as build chain in the cygwin distro, using your package. I need to use Yaakov one. So I need a working alternative. I doubt any linux distribution will accept to release a key tool that doesn't follow the distri guideline. > > > > Bottom line: we insist that the CMake in the Cygwin > distro not define > > WIN32. If you're prepared to handle that > upstream now, great. If not, > > we will need to ship a patched version until this > issue is rectified. > > How do you wish to proceed? > > > > > I guess you could release a patched cygwin that defaults to > having the policy set to new, and I could release one that > has the policy set to warn by default. > > I suppose one other options is something like this: > > "Warning: CMake has be forced to break backwards > compatibility by the cygwin ports maintainers, we apologize > if this broke your code. If your code does not compile, then > set the cygwin policy to OLD, or add if(CYGWIN) set(WIN32 1) > to your code." I am not familiar with the cmake policy stuff. But it seems a workable solution. > > We could emit that warning when cmake is run on cygwin for > all projects until they require a new enough CMake that > contains these changes by using the policy mechanism. > > I would like to proceed by using the standard cmake policy > mechanism. However, you have made it clear you will not be > happy with that approach. > > I am curious what you mean by "will need to ship a patched > version until this issue is rectified."? Will you > block me from being the CMake maintainer for cygwin > somehow? This is something we would like to avoid, as the fallout will damage both the communities (cmake and cygwin). Think of it as our last desperate solution (nuclear one). > Sorry this is becoming so difficult. I seriously just > care about the existing CMake users and don't want to break > things for them. > > -Bill Same for us. Cygwin users "usually" expect cygwin tools to build cygwin programs, not strange hybrid. Marco ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin
--- Lun 25/10/10, Hendrik Sattler ha scritto: > Am Montag 25 Oktober 2010, 05:44:27 > schrieb Yaakov (Cygwin/X): > > On Sun, 2010-10-24 at 10:12 +0200, Hendrik Sattler > wrote: > > > And: believe it or not, WIN32 and CYGWIN are > _not_ in strong contrast. > > > They've got so much in common, starting from the > binary file format to > > > all low level stuff that cygwin is never going to > change. Live with it. > > > > The "low-level stuff" -- IOW the usage of PE binaries > -- is about *all* > > Cygwin has in common with Win32. Everything > above that, including the > > No. You have the same kernel under the skin and any > software that has low- > level parts thus needs to know that it is running on > Windows, be it through > the cygwin layer or not. How does it do that without the > WIN32 define? this type of package are less than 1% of total. All the others pass through the cygwin layer. The vast majority of packages ignore cygwin and built fine following the IF(LINUX) conditionals, bur if there are also IF(WIN32) conditionals we arrive with a deathly mix of unix and win32 characteristics. This make the porting job a tiring job, and it is the main reason why very few cmake built package are inside the cygwin distribution. I hit this problem for every package I tried and the easy solution is to use a cmake that don't set WIN32, than the porting is almost a piece of cake. I built also VTK as truly cygwin package in this way. > > > usage of *NIX/X11 vs Win32/GDI APIs is different, and > that represents > > the bulk of IF(WIN32) usage. > > And for the cases it doesn't? You don't throw away > compatibility for "the bulk > of ...". This compatibility is a great damage to our efforts to include whatever package in the cygwin distributin. Eventually you could add a cygwin-legacy mode to mantain the current WRONG (for us cygwin mantainers) WIN32 setting. > > HS Marco ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin
--- Dom 24/10/10, Hendrik Sattler ha scritto:
> Am Sonntag 24 Oktober 2010, 08:37:30
> schrieb Marco Atzeri:
> > It should be changed. That will be the cleanest way
> for porting and
> > most of the time we will not need any IF (CYGWIN) to
> complete our job
> > as package maintainer.
> >
> > Othewise we should patch any sources to replace IF
> (WIN32) with
> > IF(WIN32 AND NOT CYGWIN) and these means that this
> wrong policy
> > is forcing unneeded workload on our backs.
> >
> > Also cmake and vtk sources are full of IF(WIN32 AND
> NOT CYGWIN)
> > because WIN32 and CYGWIN are in strong contrast.
>
> No, they are not. There are certain things in cygwin that
> are so WIN32 like.
> I have the following in my CMakeLists for OpenOBEX:
I do not see openobex as a package ported to cygwin
http://cygwin.com/packages/
> if ( CMAKE_COMPILER_IS_GNUCC )
> if ( UNIX AND NOT WIN32 )
> set ( COMPILER_FLAG_VISIBILITY
> -fvisibility=hidden )
> check_c_compiler_flag (
> ${COMPILER_FLAG_VISIBILITY}
>
>
> COMPILER_SUPPORT_VISIBILITY )
> endif ( UNIX AND NOT WIN32 )
> [...]
>
> because on WIN32, the DLLEXPORT is used instead. So your
on cygwin DLLEXPORT is handled directly by the compiler gcc.
There is no need of a special handling on top of Unix one
for a true cygwin package.
> proposal really
> breaks working setups while trying to fix it for those
> upstreams that cannot
> read documentation? That sucks.
>
> And: believe it or not, WIN32 and CYGWIN are _not_ in
> strong contrast. They've
> got so much in common, starting from the binary file format
> to all low level
> stuff that cygwin is never going to change. Live with it.
sorry no. We work very hard to make cygwin as mach as possible
unix compatible and break the un-needed win32 heritage and
mis-understandings of what cygwin is.
I am cygwin package mantainer for 14 packages, and Yaakov handle
almost a third of all cygwin packages.
(see http://cygwin.com/cygwin-pkg-maint)
So I presume we have a better idea of you about what means porting
any package to cygwin as effort.
>
> HS
>
Marco
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin
--- Ven 22/10/10, Rolf Eike Beer ha scritto: > > This super-set is wrong. Cygwin belongs to Unix > family > > Exactly. And guess what: "IF (UNIX)" would also include > Cygwin. > > > I noticed. But Automake/autoconf makes it right, it > > doesn't mix cygwin with win32 programs. > > Well, you did not ask right ;) > > IF (UNIX) > foo > ENDIF() > > -> Cygwin would say foo > > IF (WIN32) > foo > ENDIF () > > -> Cygwin would say foo > > IF (CYGWIN) > foo > ENDIF () > > -> well, you guess it > > So this is only different from what other build tools or > whatever do. But > it is well known behaviour, it is documented, and it can't > be changed for > backward compatibility anyway. It should be changed. That will be the cleanest way for porting and most of the time we will not need any IF (CYGWIN) to complete our job as package maintainer. Othewise we should patch any sources to replace IF (WIN32) with IF(WIN32 AND NOT CYGWIN) and these means that this wrong policy is forcing unneeded workload on our backs. Also cmake and vtk sources are full of IF(WIN32 AND NOT CYGWIN) because WIN32 and CYGWIN are in strong contrast. > > >> > Checking for CYGWIN in the CMakeLists.txt > >> > oblige to modify upstream source for any > package > >> > we want to port on cygwin. While not setting > WIN32 > >> > allow to use upstream source without change > and > >> building > >> > like any other Unix system. > >> > >> Not checking for CYGWIN is an error in the > upstream package > >> and should be reported there or patched by you. > > > > This is absurd. > > The upstream could ignore CYGWIN, but I as package > maintainer > > I should not patch every single package when NOT > setting > > WIN32 allow me to build from the source of the shelf. > > Ehm, if the upstream writes a CMakeLists.txt it should > write a valid one. > > > To build qhull (http://www.qhull.org/) > > I needed no cygwin specific patch, but only a cmake > package > > with a RIGHT understanding of what Cygwin is: > SET(WIN32 0) > > > > Also VTK builds as true cygwin programs with SET(WIN32 > 0) > > Those are bugs, report them. For me and almost all the other cygwin package maintainers, it is a wrong behaviour of cmake so I am reporting here. (Bill of course could disagree, but its only cygwin package is cmake) > > Eike Marco Atzeri ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin
--- Ven 22/10/10, David Cole ha scritto: >This depends on your perspective. Are you using cygwin to try > to make a native Windows port of a Unix program, or are you > simply trying to compile the Unix program as if it was still > Unix (and thereby trap it in the cygwin environment)? My perspective is very simple. I am a cygwin package maintainer. So I expect that cmake on cywin builds cygwin programs, not something else. When I want to compile mingw-programs, I use the mingw64-i686-gcc cross compiler (cygwin to mingw) not gcc ( cygwin to cygwin). > We have been used to people saying they want to build native > Windows apps with cygwin... and that's why it is the way it > is. Perhaps there would be less cygwin-angst in the cmake > world if we had adopted the opposite perspective, but that's > the way it's been. > If we change it now, it should be changed via a cmake policy > so that it's easy to get both behaviors for a while... if cmake don't change it useless for porting to cygwin. And this is really blocking the port of a lot of packages. I don't like to build my own version of cmake to overcome the current setting of the cmake cygwin package. Regards Marco ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin
--- Ven 22/10/10, Michael Wild ha scritto: > >> > >> That's why one should check for CYGWIN in the > >> CMakeLists.txt files. IMHO this is a user-error > and not > >> CMake's fault. The doc clearly states about the > WIN32 > >> variable: > >> > >> WIN32 True on > windows > >> systems, including win64. > > > > But for cygwin is WRONG. It should be false > > One could also argue that cygwin is running under WIN32. A > matter of convention. Sorry again, but you are wrong. It is not a convention, Cygwin is a unix platform. Cygwin programs don't work as usual win32 programs > > > > > WIN32 in not defined when you compile for cygwin any > > package. > > It is defined if your target is non cygwin but a pure > > win32 program like mingw ones. > > Eg. Autoconf/Automake don't set WIN32. > > WIN32 is the super-set of pure Windows, CYGWIN and > MSYS/MINGW. And in case you haven't noticed: CMake is not a > Autoconf clone... This super-set is wrong. Cygwin belongs to Unix family I noticed. But Automake/autoconf makes it right, it doesn't mix cygwin with win32 programs. > > Checking for CYGWIN in the CMakeLists.txt > > oblige to modify upstream source for any package > > we want to port on cygwin. While not setting WIN32 > > allow to use upstream source without change and > building > > like any other Unix system. > > Not checking for CYGWIN is an error in the upstream package > and should be reported there or patched by you. This is absurd. The upstream could ignore CYGWIN, but I as package maintainer I should not patch every single package when NOT setting WIN32 allow me to build from the source of the shelf. To build qhull (http://www.qhull.org/) I needed no cygwin specific patch, but only a cmake package with a RIGHT understanding of what Cygwin is: SET(WIN32 0) Also VTK builds as true cygwin programs with SET(WIN32 0) > > My 2c. > > Michael > Marco ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake for cygwin
--- Ven 22/10/10, Michael Wild ha scritto: > > On 22. Oct, 2010, at 11:07 , Marco Atzeri wrote: > > > Dear developers, > > the current cmake package for cygwin is unsuitable to > build > > cmake package as it defines WIN32. > > Cygwin programs are unix-like ones while WIN32 is > needed only > > for pure windows programs. > > Defining WIN32 breaks building normal unix programs. > > > > To build the last qhull package > > http://cygwin.com/ml/cygwin-announce/2010-09/msg00015.html > > I was obliged to use the cmake Ports version. > > > > http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=devel/cmake;hb=HEAD > > > > Using such package I was also able to build VTK, with > very minor > > change of the source. > > http://www.vtk.org/pipermail/vtk-developers/2010-September/008590.html > > > > > > As the first target of a cygwin package is to allow > to > > build other cygwin packages, the current package > > does NOT satisfy this requirement. > > > > Regards > > Marco > > That's why one should check for CYGWIN in the > CMakeLists.txt files. IMHO this is a user-error and not > CMake's fault. The doc clearly states about the WIN32 > variable: > > WIN32 True on windows > systems, including win64. But for cygwin is WRONG. It should be false WIN32 in not defined when you compile for cygwin any package. It is defined if your target is non cygwin but a pure win32 program like mingw ones. Eg. Autoconf/Automake don't set WIN32. Checking for CYGWIN in the CMakeLists.txt oblige to modify upstream source for any package we want to port on cygwin. While not setting WIN32 allow to use upstream source without change and building like any other Unix system. > > Set to > true when the target system is Windows and on cygwin. > > Michael Marco ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake for cygwin
Dear developers, the current cmake package for cygwin is unsuitable to build cmake package as it defines WIN32. Cygwin programs are unix-like ones while WIN32 is needed only for pure windows programs. Defining WIN32 breaks building normal unix programs. To build the last qhull package http://cygwin.com/ml/cygwin-announce/2010-09/msg00015.html I was obliged to use the cmake Ports version. http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=devel/cmake;hb=HEAD Using such package I was also able to build VTK, with very minor change of the source. http://www.vtk.org/pipermail/vtk-developers/2010-September/008590.html As the first target of a cygwin package is to allow to build other cygwin packages, the current package does NOT satisfy this requirement. Regards Marco CYGWIN.cmake Description: Binary data ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
