Thanks; I gave up on trying to get long filenames to work. There are too many 
levels involved, and if you get it right on 1-n, then n+1 messes it up, etc., 
etc.

Right, the I took out the FORCE_C_COMPILER stuff. But it still breaks things it 
shouldn't.

z/OS is indeed not the only OS on System z; that's why I was asking before 
about the nomenclature (OS vs. platform etc.).  The good news is, anybody on 
System z knows about z/OS and knows that it's the "big dog", so we're OK using 
that name, rather than ANY_SYSTEM_Z_OS or something (!).  (I came from the 
world of one of the other System z OSes, so I think I can say that with some 
confidence: we've spent decades reminding people that "z/OS" isn't the only OS, 
but given that we have to choose something...)

Once this finally settles down once and for all (we're still fighting other 
fires, but I think CMake is a resolved issue) I'll look into submitting a patch.

Related question: I hacked CheckTypeSize.cmake to MESSAGE the OUTPUT variable 
after a compile, since it was claiming to work but actually failing (leaving no 
values for the types in CMakeCache.txt).  Some grepping of the CMAKE files and 
the source failed to reveal any way that the --debug_output flag was exposed to 
the macros; did I miss it?  It would be nice to have a way to see the compiler 
output.

...phsiii
-----Original Message-----
From: Alexander Neundorf [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 6:04 PM
To: Phil Smith
Cc: [email protected]
Subject: Re: [CMake] Cross-compiling for z/OS -- linker question

On Monday 25 August 2008, Phil Smith wrote:
> I'm back on this, after a week at a conference and a week of vacation.
>
> I have the GET_FILENAME_COMPONENT call working, and it returns what I'd
> expect (c:/progra~1/dignus), but the FIND_PROGRAM resolves the path with
> blanks (c:/Program Files/Dignus/plink.exe).  Here's the CMAKE code I'm
> using, in ZOS.cmake:
>
> GET_FILENAME_COMPONENT(PLINKPATH "${CMAKE_C_COMPILER}" PATH)
> MESSAGE(STATUS "PLINK path is ${PLINKPATH}!")
> FIND_PROGRAM(PLINK_EXECUTABLE NAMES plink PATHS "${PLINKPATH}"
> NO_DEFAULT_PATH) MESSAGE(STATUS "PLINK_EXECUTABLE is ${PLINK_EXECUTABLE}!")
> SET(CMAKE_CXX_LINK_EXECUTABLE "${PLINK_EXECUTABLE}
> \"-Sc:/progra~1/dignus/objs_rent/&M\" <OBJECTS> -o <TARGET>")
> SET(CMAKE_C_LINK_EXECUTABLE   "${PLINK_EXECUTABLE}
> \"-Sc:/progra~1/dignus/objs_rent/&M\" <OBJECTS> -o <TARGET>")
>
> That barfs all over the place. The two MESSAGE calls show:
> -- PLINK path is c:/progra~1/dignus!
> -- PLINK_EXECUTABLE is C:/Program Files/Dignus/plink.exe!
> (And if I put the "progra~1"-format path back in manually, it works again.)

Hmm, the output from MESSAGE() looks as I would expect. What's wrong with
it/what exactly does "barfs all over the place" mean ?

> I also realized that I think there will be a change needed to
> CheckTypeSize.cmake after all: the -fasciiout flag only makes sense during
> that call, as during actual compiles, one will NOT want it set.  Something
> like (around line 60): IF(ZOS)
>       SET(MACRO_CHECK_TYPE_SIZE_FLAGS "${MACRO_CHECK_TYPE_SIZE_FLAGS}
> -fasciiout") ENDIF(ZOS)

Hmm, looks ugly but maybe we'll have to do something like this :-/

> Finally, I'm also still trying to figure out how to name things most
correctly.  You said a couple of things before:
> >Well, the initial tests for the compiler should work without the
> >CMakeForceCompiler stuff. If this works, then CMakeC[XX]CompilerId.c.in
> > cmake should be able to detect that it's the Dignus compiler, and set
> >CMAKE_C_COMPILER_ID to "Dignus". Once this is works, it then tries to load
> >Modules/Platform/ZOS-Dignus-C.cmake (and ZOS-Dignus-CXX.cmake).
> >These files should then contain the settings which are specific for that
> >combination of operating system, and compiler.
> >E.g CMAKE_C_LINK_EXECUTABLE and maybe more.
>
> and:
> > No, it's <SYSTEM>-<COMPILER_ID>-<LANGUAGE>.cmake
> >with SYSTEM being the name of the operating system.
>
> But what I don't see is how it's going to figure out that the compiler is
> named Dignus, since the CMAKE_FORCE_C_COMPILER stuff breaks everything.

"breaks everything" ?
Aren't we trying right now to get rid of the FORCE_C_COMPILER stuff ? It
shouldn't break anything, since it's not called anymore :-)

> Maybe I don't care that much that the compiler gets identified fully -- do
> I?  It's the one and only likely compiler to be used for z, now and forever

But I guess zOS is not the only OS the compiler can be used for ?
So getting this to work should help using Dignus on other platforms.

Alex
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to