[CMake] Observation regarding Utilities/cmliblzma/CMakeLists.txt
After some rather extensive banging of my head on my desk trying to resolve a variable definition issue I finally tracked it down to the Utilities/cmliblzma/CMakeLists.txt file. Line 26 contains the following statement: CHECK_INCLUDE_FILE(inttypes.h HAVE_INTTYPES_H) Absolutely nothing wrong with this EXCEPT while it CHECKS for that header file... it appears that this file never actually INCLUDES the header file later (beginning at line 79) when it starts to check type and size of data types: CHECK_TYPE_SIZE(int16_t INT16_T) After some digging in the documentation I spotted this in the list of variables which can get set before calling this macro: CMAKE_EXTRA_INCLUDE_FILES = list of extra headers to include Ultimately I worked around the compiler errors by adding the following inside a test for the OpenVMS operating system: if( (CMAKE_CXX_PLATFORM_ID MATCHES "OpenVMS") AND HAVE_INTTYPES_H ) SET( CMAKE_EXTRA_INCLUDE_FILES "inttypes.h" ) endif() It seems odd to me that someone would have to do this since the CMake build procedure had already gone painstaking tests to generate the ABI.h and INT.h header files for the operating system and in so doing had already identified the available/necessary data types. /SenseiC bows out -- 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] CMake port to OpenVMS - confusing behavior in cmliblzma code tree, specifically the config.h file generated from config.h.in
After somewhat of an archeological dig I have finally traced down the following error message: [ 12%] Building C object Utilities/cmliblzma/CMakeFiles/cmliblzma_dir/liblzma/check/check.c.o cd /PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma && /bin/cc -Wc/warnings=disable=all/lis/show=all -w -I/PRJ_ROOT/CMAKE-3_3_2/Utilities -I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma/common -I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma/liblzma/api -I/PRJ_ROOT/CMAKE-3_3_2/ Utilities/cmliblzma/liblzma/check -I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma/liblzma/common -I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmlib lzma/liblzma/delta -I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma/liblzma/lz -I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma/liblzma/lzma - I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma/liblzma/rangecoder -I/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblzma/liblzma/simple -I/PRJ_ROOT /CMAKE-3_3_2/Utilities/cmliblzma-o CMakeFiles/cmliblzma_dir/liblzma/check/check.c.o -c /PRJ_ROOT/CMAKE-3_3_2/Utilities/cmliblz ma/liblzma/check/check.c typedef uint64_t uintptr_t; ^ %CC-E-NOLINKAGE, In this declaration, "uint32_t" has no linkage and has a prior declaration in this scope at line number 174 in file LCL_ROOT:[cmake-3_3_2.Utilities.cmliblzma]config.h;7. at line number 75 in module INTTYPES of text library SYS$COMMON:[SYSLIB]DECC$RTLDEF.TLB;1 make[2]: *** [Utilities/cmliblzma/CMakeFiles/cmliblzma_dir/liblzma/check/check.c.o] Error 2 make[2]: Leaving directory `/PRJ_ROOT/CMAKE-3_3_2' make[1]: *** [Utilities/cmliblzma/CMakeFiles/cmliblzma_dir/all] Error 2 make[1]: Leaving directory `/PRJ_ROOT/CMAKE-3_3_2' make: *** [all] Error 2 to a somewhat confusing (at least to me) behavior of the config.h header file generated from the config.h.in file. Line Statement 6/* First, we need to know if the system has already defined them. */ 7#cmakedefine HAVE_INT16_T 8#cmakedefine HAVE_INT32_T 9#cmakedefine HAVE_INT64_T 10#cmakedefine HAVE_INTMAX_T 11 12#cmakedefine HAVE_UINT8_T 13#cmakedefine HAVE_UINT16_T 14#cmakedefine HAVE_UINT32_T 15#cmakedefine HAVE_UINT64_T 16#cmakedefine HAVE_UINTMAX_T Generates these statements in the config.h header file 6/* First, we need to know if the system has already defined them. */ 7/* #undef HAVE_INT16_T */ 8/* #undef HAVE_INT32_T */ 9/* #undef HAVE_INT64_T */ 10/* #undef HAVE_INTMAX_T */ 11 12/* #undef HAVE_UINT8_T */ 13/* #undef HAVE_UINT16_T */ 14/* #undef HAVE_UINT32_T */ 15/* #undef HAVE_UINT64_T */ 16/* #undef HAVE_UINTMAX_T */ Except the generated files Bootstrap_cmk/cmIML/int.h and Utilities/cmIML/int.h (which contain identical content) contain the following sections: #if defined(__VMS) # define cmIML_INT_NO_STDINT_H # define cmIML_INT_HAVE_INTTYPES_H #endif And #if defined(cmIML_INT_HAVE_STDINT_H) || defined(cmIML_INT_HAVE_INTTYPES_H) #define cmIML_INT_HAVE_INT8_T 1 #define cmIML_INT_HAVE_UINT8_T 1 #define cmIML_INT_HAVE_INT16_T 1 #define cmIML_INT_HAVE_UINT16_T 1 #define cmIML_INT_HAVE_INT32_T 1 #define cmIML_INT_HAVE_UINT32_T 1 #define cmIML_INT_HAVE_INT64_T 1 #define cmIML_INT_HAVE_UINT64_T 1 #define cmIML_INT_NO_INTPTR_T 1 #define cmIML_INT_NO_UINTPTR_T 1 #endif Near as I can tell no connection exists between the HAVE_xyz_T macros and the cmIML_INT_HAVE_xyz_T macros. Likewise I can't seem to find anywhere that would actually define the HAVE_xyz_T macros which seems equally confusing. Aside from having to manually edit the config.h.in can anyone suggest a way to work this? Jay -- 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] Question about the "logic" behind Utilities/KWIML/INT.h.in statement: @KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_intptr_t, sizeof(void*));
Probably a moot question at this point... I posed the same question to some of
the language/compiler experts at HPE and got the following explanation:
Looking quickly, I suspect that he is not using the /pointer=long qualifier at
compile time.
The default pointer size is 32-bit (4 bytes), but there are a few different
ways to get 64-bit pointers. The /pointer=long is the easiest.
Hope this helps.
05>hpcc/pointer=long ptr_test
05>link ptr_test
05>r ptr_test
sizeof(intptr_t) = 8
sizeof(uintptr_t) = 8
sizeof(void *) = 8
sizeof(int *) = 8
05>
-Original Message-
From: Custin, Jay (CSC Sw Middleware)
Sent: Thursday, November 05, 2015 1:28 PM
To: cmake@cmake.org
Subject: Question about the "logic" behind Utilities/KWIML/INT.h.in statement:
@KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_intptr_t, sizeof(void*));
>From INT.h.in:
828 #if !defined(@KWIML@_INT_NO_INTPTR_T)
829 @KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_intptr_t, sizeof(void*));
830 #endif
831 #if !defined(@KWIML@_INT_NO_UINTPTR_T)
832 @KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_uintptr_t, sizeof(void*));
833 #endif
Now this statement blows up in the make Makefile process as follows:
cmIML_INT__VERIFY_TYPE(cmIML_INT_intptr_t, sizeof(void*)); ^
%CXX-E-NOTCOMPREDEC, declaration is incompatible with
"int (*cmIML_INT_intptr_t__VERIFY__)[4U]" (declared at line 829) at
line number 829 in file LCL_ROOT:[cmake-3_3_2.Bootstrap_cmk.cmIML]INT.h;11
I wrote a simple C application to confirm the compiler's values,
compiled-and-linked the application on both OpenVMS and Fedora Linux (x64) and
noticed a discrepancy...
ITAN1* ty foo.c
#include
#include
#include
int main(void) {
printf( "sizeof(intptr_t) = %d\n", sizeof(intptr_t));
printf( "sizeof(uintptr_t) = %d\n", sizeof(uintptr_t));
printf( "sizeof(void *) = %d\n", sizeof(void *));
return EXIT_SUCCESS;
}
On OpenVMS this application displays the following:
ITAN1* r foo
sizeof(intptr_t) = 8
sizeof(uintptr_t) = 8
sizeof(void *) = 4
sizeof(int *) = 4
and clearly sizeof(void *) = 4 < does NOT equal > sizeof(intptr_t) = 8
On Fedora22 the exact same application displays the following:
[jpcustin@localhost ~]$ ./foo
sizeof(intptr_t) = 8
sizeof(uintptr_t) = 8
sizeof(void *) = 8
sizeof(int *) = 8
[jpcustin@localhost ~]$
http://en.cppreference.com/w/c/types/integer describes intptr_t as: "integer
type capable of holding a pointer"
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html goes a
little further:
Integer types capable of holding object pointers
The following type designates a signed integer type with the property that any
valid pointer to void can be converted to this type, then converted back to a
pointer to void, and the result will compare equal to the original pointer:
intptr_t
The following type designates an unsigned integer type with the property that
any valid pointer to void can be converted to this type, then converted back to
a pointer to void, and the result will compare equal to the original pointer:
uintptr_t
This begs the question...
Why does the CMake test rely on checking if sizeof(intptr_t) equals sizeof(void
*)
instead of sizeof(intptr_t) greater than or equal to sizeof(void *)
(so can an intptr_t "hold" a void *)?
JayC
--
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] Question about the "logic" behind Utilities/KWIML/INT.h.in statement: @KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_intptr_t, sizeof(void*));
>From INT.h.in:
828 #if !defined(@KWIML@_INT_NO_INTPTR_T)
829 @KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_intptr_t, sizeof(void*));
830 #endif
831 #if !defined(@KWIML@_INT_NO_UINTPTR_T)
832 @KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_uintptr_t, sizeof(void*));
833 #endif
Now this statement blows up in the make Makefile process as follows:
cmIML_INT__VERIFY_TYPE(cmIML_INT_intptr_t, sizeof(void*));
^
%CXX-E-NOTCOMPREDEC, declaration is incompatible with
"int (*cmIML_INT_intptr_t__VERIFY__)[4U]" (declared at line 829)
at line number 829 in file LCL_ROOT:[cmake-3_3_2.Bootstrap_cmk.cmIML]INT.h;11
I wrote a simple C application to confirm the compiler's values,
compiled-and-linked the application on both OpenVMS and Fedora Linux (x64) and
noticed a discrepancy...
ITAN1* ty foo.c
#include
#include
#include
int main(void) {
printf( "sizeof(intptr_t) = %d\n", sizeof(intptr_t));
printf( "sizeof(uintptr_t) = %d\n", sizeof(uintptr_t));
printf( "sizeof(void *) = %d\n", sizeof(void *));
return EXIT_SUCCESS;
}
On OpenVMS this application displays the following:
ITAN1* r foo
sizeof(intptr_t) = 8
sizeof(uintptr_t) = 8
sizeof(void *) = 4
sizeof(int *) = 4
and clearly sizeof(void *) = 4 < does NOT equal > sizeof(intptr_t) = 8
On Fedora22 the exact same application displays the following:
[jpcustin@localhost ~]$ ./foo
sizeof(intptr_t) = 8
sizeof(uintptr_t) = 8
sizeof(void *) = 8
sizeof(int *) = 8
[jpcustin@localhost ~]$
http://en.cppreference.com/w/c/types/integer describes intptr_t as: "integer
type capable of holding a pointer"
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html goes a
little further:
Integer types capable of holding object pointers
The following type designates a signed integer type with the property that any
valid pointer to void can be converted to this type, then converted back to a
pointer to void, and the result will compare equal to the original pointer:
intptr_t
The following type designates an unsigned integer type with the property that
any valid pointer to void can be converted to this type, then converted back to
a pointer to void, and the result will compare equal to the original pointer:
uintptr_t
This begs the question...
Why does the CMake test rely on checking if sizeof(intptr_t) equals sizeof(void
*)
instead of sizeof(intptr_t) greater than or equal to sizeof(void *)
(so can an intptr_t "hold" a void *)?
JayC
--
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] CMake on OpenVMS - Bootstrap CMake complaining that “pid_t doesn’t exist on this platform?”
Please disregard my query regarding pid_t. Apparently something “lingered” around in my code environment. When I wiped out the code tree leaving nothing except my VMS-related modifications and rebuilt CMake it built without the pid_t error. Go figure. Back to trying to determine where the bootstrapped CMake of the CMake code (to generate the final “image”) fails). JayC -- 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] CMake on OpenVMS - Bootstrap CMake complaining that “pid_t doesn’t exist on this platform?”
Still kicking myself… “normally” I would “delete” files that I had modified by
first renaming them to “hide” them and only then actually delete them… Well
sure enough the one time I feel confident apparently I whacked something I
shouldn’t have (guessing)…
Regardless of which the CMake execution at the tail end of the bootstrap now
complains about pid_t not existing… as you can see in the following excerpt
from manually executing the command with the –trace option:
/PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(246): set(PID_T_KEYS )
/PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(247): set(_map_file
${CMAKE_BINARY_DIR}/${CMAKE_FILES_DIRECTORY}/CheckTypeSize/PID_T.cmake )
/PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(248): if(NOT DEFINED
HAVE_PID_T )
/PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(251): include(${_map_file}
OPTIONAL )
/PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(252): set(_map_file )
/PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(253): set(_builtin )
/PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(256): if(PID_T_KEYS )
/PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(265): elseif(PID_T )
/PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(267): else()
/PRJ_ROOT/CMAKE-3_3_2/Modules/CheckTypeSize.cmake(268): set(PID_T_CODE /*
#undef PID_T */ )
/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmlibarchive/CMakeLists.txt(1128): IF(NOT
HAVE_PID_T )
/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmlibarchive/CMakeLists.txt(1129): IF(WIN32 )
/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmlibarchive/CMakeLists.txt(1131): ELSE(WIN32 )
/PRJ_ROOT/CMAKE-3_3_2/Utilities/cmlibarchive/CMakeLists.txt(1132):
MESSAGE(FATAL_ERROR pid_t doesn't exist on this platform? )
CMake Error at Utilities/cmlibarchive/CMakeLists.txt:1132 (MESSAGE):
pid_t doesn't exist on this platform?
I > thought < about simply tweaking the code to override the apparent “missing”
definition, but then decided that clearly something else prevents CMake from
finding it and so thought I would pose the question here to see if anyone has
any ideas.
The problem with this comes from knowing for certain that pid_t DOES exist in
the default HP C header:
ITAN1> sea/num unistd.h "ifndef __PID_T"/win=(0,3)
353 # ifndef __PID_T
354 # define __PID_T 1
355 typedef __pid_t pid_t;
356 # endif
And
ITAN1> sea unistd.h/num "types.h"
31 #include
ITAN1> sea types.h /num/win=(0,3) "#if !defined __PID_T"
104 #if !defined __PID_T && !defined _DECC_V4_SOURCE
105 # define __PID_T 1
106 typedef __pid_t pid_t;
107 #endif
The error occurs in this section of Utilities/cmlibarchive/CMakeLists.txt:
Line#
1127 CHECK_TYPE_SIZE(pid_t PID_T)
1128 IF(NOT HAVE_PID_T)
1129IF(WIN32)
1130 SET(pid_t "int")
1131ELSE(WIN32)
1132 MESSAGE(FATAL_ERROR "pid_t doesn't exist on this platform?")
1133ENDIF(WIN32)
1134 ENDIF(NOT HAVE_PID_T)
Anyone have any ideas?
JayC
--
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] CMake on OpenVMS - Apparent roadblock buried within cmake-3.3.2\Tests\CMakeLists.txt
Well one thing that DOES still concern me... this matter of the LF vs CRLF issue and the CMakeLists.txt file. I do need to investigate if that simply doesn't factor in when run from the GNV Bash shell, but I would certainly like to avoid having to manually tweak the file. At the moment I don't consider that that big of a deal so down on the To Do list. -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Hoffman Sent: Friday, October 30, 2015 12:00 PM To: cmake@cmake.org Subject: Re: [CMake] CMake on OpenVMS - Apparent roadblock buried within cmake-3.3.2\Tests\CMakeLists.txt On 10/30/2015 11:18 AM, Custin, Jay (CSC Sw Middleware) wrote: > Interrupting/preventing the automatic execution of the bootstrapped > CMake in the end of the bootstrap script and then try to execute it > from the shell prompt using the same basic switches I used for the > "simple" project above. This sounds like a good plan. You have a basic makefile working! That is pretty cool. I would run everything from bash all the time. Next step would be to run the bootstrapped cmake from the bash shell on CMake itself. Must be a configure file or execute_process in there that is messing things up. But hey, you have the basic CMake working! -Bill -- 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 -- 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] CMake on OpenVMS - Apparent roadblock buried within cmake-3.3.2\Tests\CMakeLists.txt
Q: What makes you think there is a problem in Tests/CMakeLists.txt?
A: Certainly the "problem" could exist in any of the myriad of files that get
processed as a result of the Tests/CMakeLists.txt file, but I base my
hypothesis on the following MESSAGE statements which I added to the main
CMakeLists.txt file:
MESSAGE( STATUS "CMAKELISTS.TXT Marker 17 add_subdirectory(Tests)" )
add_subdirectory(Tests)
MESSAGE( STATUS "CMAKELISTS.TXT Marker 18")
And when I execute the configure script (or manually execute the equivalent
CMake execution at the tail end of the bootstrap) I see the following:
-- Marker 16g add_subdirectory(Utilities)
-- CMAKELISTS.TXT Marker 17 add_subdirectory(Tests)
-- if(DEFINED ENV{HOME} AND NOT CTEST_NO_TEST_HOME) ==> TRUE
<
And NEVER see the "CMAKELISTS.TXT Marker 18") appear in the output... so it
"enters" the statement:
add_subdirectory(Tests)
on a "one-way ticket" (meaning it appears to never return to the
parsing/calling CMakeLists.txt file)
> Does anyone know where (specifically) I should investigate to
> determine where the Makefile itself should get generated?
>
What files are generated in the build tree?
For the moment skipping this question in lieu of pursuing your suggestion of
the results of using the bootstrapped CMake to configure a simple project
further (below)
The toplevel makefile is created here:
void cmGlobalUnixMakefileGenerator3::WriteMainCMakefile()
But there are lots of other files that get created.
One thing you could try is to use the bootstrapped cmake to configure a more
simple project. Something like:
project(foo)
add_library(foo foo.c)
foo.c can be an empty file.
Does the bootstrapped cmake work on that project?
Initially I feared that I would have to answer "No", but after some further
excavation I did make some significant progress (which probably also reveals
some things that still, not surprisingly, need more tweaking).
ITAN1* cmake "-DCMAKE_BOOTSTRAP=1"
CMake Error: Error in cmake code at
/JAY/CMAKE/CMakeLists.txt:1:
Parse error. Expected a newline, got identifier with text "add_library".
-- Configuring incomplete, errors occurred!
ITAN1* d
Directory JAY:[cmake]
CMakeCache.txt;1CMakeFiles.DIR;1cmakelists.txt;5foo.c;1
After beating my head on the desk for a while... I finally decided to beat the
cmakelists.txt file instead (force the file structure on the file - thank you
OpenVMS for defaulting to CRLF) and after that I managed to get the following
result:
ITAN1* ty *.*
JAY:[cmake]cmakelists.txt;10
project(foo)
add_library(foo foo.c)
JAY:[cmake]foo.c;3
#include
main()
{
printf("Hello World");
}
ITAN1*
I did try my level-headed best to get this to work from the OpenVMS DCL prompt
directly, but (at the moment) without success. That said... from the GNV Bash
prompt I did (with some additional switch definitions) get it to generate the
Makefile:
So taking my simple "hello world" project files and copying them to a clean
directory:
ITAN1* create/dir jay:[cmake_simple_test]
ITAN1* copy foo.c,cmakelists.txt jay:[cmake_simple_test]/log
%COPY-S-COPIED, JAY:[cmake]foo.c;3 copied to JAY:[cmake_simple_test]foo.c;3 (1
block)
%COPY-S-COPIED, JAY:[cmake]cmakelists.txt;10 copied to
JAY:[cmake_simple_test]cmakelists.txt;10 (1 block)
%COPY-S-NEWFILES, 2 files created
ITAN1* set default jay:[cmake_simple_test]
JAY:[CMAKE_SIMPLE_TEST]
ITAN1* dir
Directory JAY:[cmake_simple_test]
cmakelists.txt;10 foo.c;3
Total of 2 files.
And switching to the GNV Bash shell it ran (in MY opinion) very cleanly, though
I did ultimately determine that I had to manually define the CMAKE_C_COMPILER
variable in the command line):
ITAN1* bash
bash-4.3$ /PRJ_ROOT/CMAKE-3_3_2/BOOTSTRAP_CMK/CMAKE -DCMAKE_BOOTSTRAP=1
-DCMAKE_C_COMPILER=/bin/cc
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Check for working C compiler: /bin/cc
-- Check for working C compiler: /bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /bin/CC
-- Check for working CXX compiler: /bin/CC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /JAY/CMAKE_SIMPLE_TEST
bash-4.3$ ls
CMakeCache.txt CMakeFiles Makefile cmake_install.cmake cmakelists.txt foo.c
Dropping back to the DCL prompt you can see it has created quie a few files:
ITAN1* dir [...]
Directory JAY:[cmake_simple_test]
CMakeCache.txt;1CMakeFiles.DIR;1cmakelists.txt;10
cmake_install.cmake;1
foo.c;3 Makefile.;1
Total of 6 files.
Directory JAY:[cmake_simple_test.CMakeFiles]
3^.3^.2.DIR;1 cmake.check_cache;2 cmake.check_cache;1
CMakeDirectoryInformation.cmake;1
CMakeError.log;1CMakeOutput.log;1 CMakeTmp.DIR;1 foo_dir.DIR;1
Makefile.cmake;1Makefile2.;1progress.marks;1
TargetDirectories.txt;
[CMake] CMake on OpenVMS - Apparent roadblock buried within cmake-3.3.2\Tests\CMakeLists.txt
I thought I had turned the final corner and only had the “home stretch” left to get to the finish line… and then a brick wall suddenly appeared to block my way… So the configuration/bootstrap script seems to blissfully get all the way to the end and even displays the following: - CMake has bootstrapped. Now run make. Except when I looked… it had not created the Makefile. I ran the same basic process on one of my Linux systems and noticed that in addition to NOT creating the Makefile… it also did not create the bin subdirectory. I tried simply adding the –trace option on the bootstrap’s cmake command (the last thing it does before posting the text above), but that didn’t seem to reveal any clues. I would love to simply comment out large swaths of the 3000+ lines of cmake-3.3.2\Tests\CMakeLists.txt but at this point I don’t have sufficient understanding of what impact doing this would have and fear that without the understanding doing so would probably do little to help me isolate where things appear to have gone awry. Does anyone know where (specifically) I should investigate to determine where the Makefile itself should get generated? What about what triggers the creation of the bin folder? Jay -- 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] CMake on OpenVMS - watching CMake build process run through its enormous number of self-tests!!!!
Cautiously optimistic... Staring at my terminal session watching self-tests execute... <> -- Performing Test HAVE_RESTRICT -- Performing Test HAVE_RESTRICT - Success -- Performing Test HAVE___RESTRICT -- Performing Test HAVE___RESTRICT - Success -- Performing Test HAVE_INLINE -- Performing Test HAVE_INLINE - Success -- Performing Test HAVE___INLINE -- Performing Test HAVE___INLINE - Success <> -- Looking for symlink -- Looking for symlink - found -- Looking for timegm -- Looking for timegm - not found -- Looking for tzset -- Looking for tzset - found -- Looking for utime -- Looking for utime - found -- Looking for utimes -- Looking for utimes - found -- 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] CMake on OpenVMS - approaching the finish line
Had a few environmental issues that bit me (and drew blood)... but have gotten
MUCH closer to the goal... except
bash-4.3$ ./configure --system-curl --system-zlib --verbose
--init=BuildCMakeOpenVMS_CacheFlags.cmake
<>
/bin/cc -Wc/warnings=disable=all -I/PRJ_ROOT/CMAKE-3_3_2/Bootstrap_cmk
-I/PRJ_ROOT/CMAKE-3_3_2/Source -I/PRJ_ROOT/CMAKE-3_3_2/Bootstrap_cmk
-DKWSYS_NAMESPACE=cmsys -c /PRJ_ROOT/CMAKE-3_3_2/Source/kwsys/Terminal.c -o
Terminal.o
cc -Wc/warnings=disable=all -I/PRJ_ROOT/CMAKE-3_3_2/Bootstrap_cmk
-I/PRJ_ROOT/CMAKE-3_3_2/Source -I/PRJ_ROOT/CMAKE-3_3_2/Bootstrap_cmk cmake.o
cmakemain.o cmcmd.o cmCommandArgumentLexer.o cmCommandArgumentParser.o
cmCommandArgumentParserHelper.o cmCPackPropertiesGenerator.o cmDefinitions.o
cmDepends.o cmDependsC.o cmDocumentationFormatter.o cmPolicies.o cmProperty.o
cmPropertyMap.o cmPropertyDefinition.o cmPropertyDefinitionMap.o cmMakeDepend.o
cmMakefile.o cmExportFileGenerator.o cmExportInstallFileGenerator.o
cmExportTryCompileFileGenerator.o cmExportSet.o cmExportSetMap.o
cmExternalMakefileProjectGenerator.o cmGeneratorExpressionEvaluationFile.o
cmGeneratedFileStream.o cmGeneratorTarget.o cmGeneratorExpressionContext.o
cmGeneratorExpressionDAGChecker.o cmGeneratorExpressionEvaluator.o
cmGeneratorExpressionLexer.o cmGeneratorExpressionNode.o
cmGeneratorExpressionParser.o cmGeneratorExpression.o cmGlobalGenerator.o
cmInstallDirectoryGenerator.o cmLocalGenerator.o cmInstalledFile.o
cmInstallGenerator.o cmInstallExportGenerator.o cmInstallFilesGenerator.o
cmInstallScriptGenerator.o cmInstallTargetGenerator.o cmScriptGenerator.o
cmSourceFile.o cmSourceFileLocation.o cmState.o cmSystemTools.o
cmTestGenerator.o cmVersion.o cmFileTimeComparison.o
cmGlobalUnixMakefileGenerator3.o cmLocalUnixMakefileGenerator3.o
cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o
cmMakefileTargetGenerator.o cmMakefileUtilityTargetGenerator.o
cmOSXBundleGenerator.o cmNewLineStyle.o cmBootstrapCommands1.o
cmBootstrapCommands2.o cmCommandsForBootstrap.o cmTarget.o cmTest.o
cmCustomCommand.o cmCustomCommandGenerator.o cmCacheManager.o cmListFileCache.o
cmComputeLinkDepends.o cmComputeLinkInformation.o cmOrderDirectories.o
cmComputeTargetDepends.o cmComputeComponentGraph.o cmExprLexer.o cmExprParser.o
cmExprParserHelper.o cmGlobalNinjaGenerator.o cmLocalNinjaGenerator.o
cmNinjaTargetGenerator.o cmNinjaNormalTargetGenerator.o
cmNinjaUtilityTargetGenerator.o cmListFileLexer.o vms_crtl_init.o Directory.o
EncodingCXX.o FStream.o Glob.o RegularExpression.o SystemTools.o EncodingC.o
ProcessUNIX.o String.o System.o Terminal.o -o cmake
-- The C compiler identification is HP
-- The CXX compiler identification is HP
-- Check for working C compiler: /bin/cc
-- Check for working C compiler: /bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /bin/cc
-- Check for working CXX compiler: /bin/cc -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
<>
-- Checking whether CXX compiler has atoll
-- Checking whether CXX compiler has atoll - yes
-- Checking whether CXX compiler has _atoi64
-- Checking whether CXX compiler has _atoi64 - no
-- Looking for C++ include execinfo.h
-- Looking for C++ include execinfo.h - not found
-- Using system-installed CURL
-- Using system-installed ZLIB
-- Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.8")
CMake Error at CMakeLists.txt:266 (message):
CMAKE_USE_SYSTEM_ZLIB is ON but a zlib is not found!
Call Stack (most recent call first):
CMakeLists.txt:533 (CMAKE_BUILD_UTILITIES)
-- Configuring incomplete, errors occurred!
See also "/PRJ_ROOT/CMAKE-3_3_2/CMakeFiles/CMakeOutput.log".
See also "/PRJ_ROOT/CMAKE-3_3_2/CMakeFiles/CMakeError.log".
-
CMake has bootstrapped. Now run make.
./configure: line 3: /PRJ_ROOT/CMAKE-3_3_2/bootstrap: error 0
bash-4.3$
It appears this error occurs during the execution of FindZLIB.cmake (I added a
MESSAGE statement and confirmed that) and when I looked at that file... this
strikes me as odd...
Lines 70-77:
70 # Normal search.
71 set(_ZLIB_SEARCH_NORMAL
72 PATHS "[HKEY_LOCAL_MACHINE\\SOFTWARE\\GnuWin32\\Zlib;InstallPath]"
73 "$ENV{PROGRAMFILES}/zlib"
74 )
75 list(APPEND _ZLIB_SEARCHES _ZLIB_SEARCH_NORMAL)
76
77 set(ZLIB_NAMES z zlib zdll zlib1 zlibd zlibd1)
Now if I have correctly guessed at this will do... this would ONLY work on a
Windows-based platforms (since *nix doesn't use Microsoft's registry keys,
thank God!, and it wouldn't go searching in {Programfiles}/zlib on a *nix
system either, I wouldn't think).
Even more confusing... at least to me... the error message clearly indicates it
has found >> a << ZLIB:
...(found version "1.2.8")
Which matches the version information of the ZLIB I have installed on the VMS
system:
ITAN1> product show product zlib
---
Re: [CMake] Continued issues in trying to get CMake working on OpenVMS
I will try adding that option and see what it may reveal... the output contained in the CMakeOutput.log and CMakeError.log offered nothing other than politely telling me the test failed. -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Hoffman Sent: Monday, September 21, 2015 10:55 AM To: cmake@cmake.org Subject: Re: [CMake] Continued issues in trying to get CMake working on OpenVMS On 9/21/2015 10:17 AM, Custin, Jay (CSC Sw Middleware) wrote: > This gets made even more frustrating in that it appears that the > testing phase does a VERY good job cleaning up after itself... So, the output should all be in CMakeOutput.log and CMakeError.log found in the build tree in the CMakeFiles directory. If you want CMake not to delete the temp files you can use --debug-trycompile http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html -Bill -- 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 -- 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] Continued issues in trying to get CMake working on OpenVMS
So I ran into a few minor issues compiling/linking the CMake images (compiler threw a few "warnings" which didn't really prove significant so I simply "silenced" the warnings to enable the code to compile clean and link). I accomplished this with the following: bash$ export CFLAGS="-Wc/warnings=disable=all" bash$ export CXXFLAGS="-Wc/warnings=disable=all" bash$ ./configure The bootstrap "happily" compiles and links ALL the code without any issues... but then CMake does some self-evaluation and things get very ugly... very fast. For whatever reason the bootstrap has no issues "finding" the various C/C++ header files to compile and link the CMake source... but when the "interim" CMake itself then tries to find them... complete and utter failure. At present I have what I would call the "interim" version of CMake built (which at this phase requires adding the option -DCMAKE_BOOTSTRAP=1 on the end of the cmake command to do much of anything). I have included an abbreviated version of this build below: bash$ export CFLAGS="-Wc/warnings=disable=all" bash$ export CXXFLAGS="-Wc/warnings=disable=all" bash$ ./configure --system-curl --system-zlib --verbose --init=BuildCMakeOpenVMS_CacheFlags.cmake - Source directory: /PRJ_ROOT/CMAKE-3_3_1 Binary directory: /PRJ_ROOT/CMAKE-3_3_1 Prefix directory: /usr/local System: OpenVMS - CMake 3.3.1, Copyright 2000-2015 Kitware, Inc. C compiler on this system is: cc -Wc/warnings=disable=all C++ compiler on this system is: CXX -Wc/warnings=disable=all %DCL-E-PARSEFAIL, error parsing DCL$PATH:"cc".* -RMS-F-FNM, error in file name Makefile processor on this system is: make %DCL-E-NOTFR, no transfer address CXX is not GNU compiler %DCL-E-NOTFR, no transfer address CXX is not SolarisStudio compiler CXX has setenv CXX has unsetenv CXX does not have environ in stdlib.h CXX has STL in std:: namespace CXX has ANSI streams CXX has streams in std:: namespace CXX has sstream CXX has operator!=(string, char*) CXX has stl iterator_traits CXX has standard template allocator CXX has allocator<>::rebind<> CXX does not have non-standard allocator<>::max_size argument CXX has stl containers supporting allocator objects CXX has stl wstring CXX has header cstddef CXX does not require template friends to use <> CXX supports member templates CXX has standard template specialization syntax CXX has argument dependent lookup CXX does not have struct stat with st_mtim member CXX has ios::binary openmode - CXX -Wc/warnings=disable=all -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_1/Source -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -c /PRJ_ROOT/CMAKE-3_3_1/Source/cmake.cxx -o cmake.o CXX -Wc/warnings=disable=all -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_1/Source -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -c /PRJ_ROOT/CMAKE-3_3_1/Source/cmakemain.cxx -o cmakemain.o CXX -Wc/warnings=disable=all -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_1/Source -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -c /PRJ_ROOT/CMAKE-3_3_1/Source/cmcmd.cxx -o cmcmd.o <> <> <> cc -Wc/warnings=disable=all -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_1/Source -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -DKWSYS_NAMESPACE=cmsys -c /PRJ_ROOT/CMAKE-3_3_1/Source/kwsys/Terminal.c -o Terminal.o CXX -Wc/warnings=disable=all -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_1/Source -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk cmake.o cmakemain.o cmcmd.o cmCommandArgumentLexer.o cmCommandArgumentParser.o cmCommandArgumentParserHelper.o cmCPackPrope rtiesGenerator.o cmDefinitions.o cmDepends.o cmDependsC.o cmDocumentationFormatter.o cmPolicies.o cmProperty.o cmPropertyMap.o cmPro pertyDefinition.o cmPropertyDefinitionMap.o cmMakeDepend.o cmMakefile.o cmExportFileGenerator.o cmExportInstallFileGenerator.o cmExp ortTryCompileFileGenerator.o cmExportSet.o cmExportSetMap.o cmExternalMakefileProjectGenerator.o cmGeneratorExpressionEvaluationFile .o cmGeneratedFileStream.o cmGeneratorTarget.o cmGeneratorExpressionContext.o cmGeneratorExpressionDAGChecker.o cmGeneratorExpressio nEvaluator.o cmGeneratorExpressionLexer.o cmGeneratorExpressionNode.o cmGeneratorExpressionParser.o cmGeneratorExpression.o cmGlobal Generator.o cmInstallDirectoryGenerator.o cmLocalGenerator.o cmInstalledFile.o cmInstallGenerator.o cmInstallExportGenerator.o cmIns tallFilesGenerator.o cmInstallScriptGenerator.o cmInstallTargetGenerator.o cmScriptGenerator.o cmSourceFile.o cmSourceFileLocation.o cmState.o cmSystemTools.o cmTestGenerator.o cmVersion.o cmFileTimeComparison.o cmGlobalUnixMakefileGenerator3.o cmLocalUnixMakefile Generator3.o cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o cmMakefileUtilityT argetGenerator.o cmOSXBundleGenerator.o cmNewLineStyle.o cmBootst
[CMake] CMake on OpenVMS (some clarification)
While I specifically want this on OpenVMS/Integrity (V8.3 or higher), I have not tried this on an Alpha yet (vast majority of the coding/builds I do involve the Integrity platform). It took some manual editing of files, etc. to get this far: <> CXX has ios::binary openmode - CXX -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_1/Source -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -c /PRJ_ROOT/CMAKE -3_3_1/Source/cmake.cxx -o cmake.o #ifndef cmIML_ABI_H .^ %CXX-E-MISSINGENDIF, the #endif for this directive is missing at line number 33 in file LCL_ROOT:[cmake-3_3_1.Bootstrap_cmk.cmIML]ABI.h;4 cmIML_INT__VERIFY_TYPE(cmIML_INT_intptr_t, sizeof(void*)); ^ %CXX-E-NOTCOMPREDEC, declaration is incompatible with "int (*cmIML_INT_intptr_t__VERIFY__)[4U]" (declared at line 839) at line number 839 in file LCL_ROOT:[cmake-3_3_1.Bootstrap_cmk.cmIML]INT.h;23 < I have the GNU Not VMS (GNV) Bash environment with the latest code base for GNV (including Perl 5.22) and CMake (3.3.1). -- 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] CMake on OpenVMS
Has ANYONE actually gotten CMake working on OpenVMS? I see numerous traces of OpenVMS riddled throughout the configuration/bootstrap code, but after spending almost two solid days trying to get past the "Configure" phase I have decided I needed to formally inquire. SenseiC -- 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
