Jack Kelly <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow wrote:
>> Jack Kelly <[EMAIL PROTECTED]> writes:
>> What happens when CFLAGS is already set in the environment or when I
>> need to just extend it. I guess what I'm looking for is the Makefile
>> syntax
>>
>> CFLAGS += something
> # Try this:
> SET(CMAKE_C_FLAGS "$ENV{CFLAGS} -fno-builtin ...")
Does that work repeadatly?
SET(CMAKE_C_FLAGS "$ENV{CFLAGS} -fno-builtin")
SET(CMAKE_C_FLAGS "$ENV{CFLAGS} -Wno-unused")
SET(CMAKE_C_FLAGS "$ENV{CFLAGS} -whatever")
Or differently asked: Does the set change the env value or just an
internal one?
>> For the mini-os.elf I thought I could set some LDFLAGS (for -T
>> minios-${ARCH}) and have it fill in the remaining parts automatically
>> as it would with ADD_EXECUTABLE in some way.
> # You could add $ENV{LDFLAGS} to the COMMAND part of the
> # ADD_CUSTOM_COMMAND, or set it up to use one of the
> # CMAKE_..._LINKER_FLAGS variables (there's a variable for EXE, MODULE,
> # SHARED and STATIC, and again, variables for DEBUG, RELEASE, etc.)
CMAKE_..._LINKER_FLAGS was what I was looking for.
>> I think what I was really asking here was how to make a pattern rule
>> here. In Unix Makefile terms:
>>
>> %.gz: %
>> gzip -9 $<
>>
>> %.o: %.S
>> gcc -D__ASSEMBLY__ <incude paths> <ASFLAGS> -c $< -o $@
> # The best way I've found so far is to define a macro to gzip what you
> # want:
> IF(NOT DEFINED GZIP_EXECUTABLE)
> FIND_PROGRAM(GZIP_EXECUTABLE gzip)
> SET(GZIP_EXECUTABLE CACHE FILEPATH "Path to GZip executable")
> ENDIF(NOT DEFINED GZIP_EXECUTABLE)
> IF(NOT GZIP_EXECUTABLE)
> MESSAGE(FATAL_ERROR "Gzip is required for building.")
> ENDIF(NOT GZIP_EXECUTABLE)
>
> MACRO(GZIP_FILE INFILE GZIPFILE)
> ADD_CUSTOM_COMMAND(
> OUTPUT "${GZIPFILE}"
> COMMAND "${GZIP_EXECUTABLE} -f -9 -c ${INFILE}>${GZIPFILE}"
> MAIN_DEPENDENCY "${INFILE}"
> COMMENT "Compress ${INFILE} to ${GZIPFILE}"
> VERBATIM)
> ENDMACRO(GZIP_FILE)
That looks nice. I guess I will put that in an include file so it is
out of the main file.
> # You can probably make this smarter (e.g., derive the gzipped file name
> # from the input file name, but I didn't bother.
>>> # You may also want to add explicit paths
>>> # (like gcc -c ${MOOSE_SOURCE_DIR}/x86_64.S) and see if it's possible to
>>> # do away with that redirection in the gzip.
>>
>> Yes to the first part. Why to the redirection? Is it worth splitting
>> that in 'gzip mini-os.elf' and 'mv mini-os.elf.gz mini-os.gz'.
> # To my mind (though I could well be wrong here) is that you mutate your
> # source files as little as possible so redirecting would be better than
> # gzip and move/copy (hint, you can use
> ${CMAKE_COMMAND} -E copy file dest
> # to copy a file in a platform independent way, as part of an
> # ADD_CUSTOM_COMMAND or so.
Then I'm stuck with redirecting as gzip has no option for the
destination name.
> # The redirection seems unwise because it relies on the shell in which
> # it executes supporting it. However, I can't find a way to do
> # redirection at build time (at configure time, it's easily done with
> # EXECUTE_PROCESS, but to make it work at build time you need to then
> # configure a cmake file and run ${CMAKE_COMMAND} -P on it, which gets
> # very messy very quickly. I gave up and just went with the >.
For me that is just fine. I assume people have a posix shell, a gcc
and gnu binutils for my own sanity.
MfG
Goswin
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
