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 ...")
# One way would be to have a file i486.cmake:
SET(ARCH i486)
# and whatever else...
And cmake automatically includes the right file then?
# A file called x86_64.cmake:
SET(ARCH x86_64)
# ...
# Put this in the CMakeLists.txt:
INCLUDE(${PLATFORM})
# and invoke cmake like so:
# cmake -DPLATFORM=x86_64 /path/to/build
That would be stupid. It should know itself what architecture to pick.
I agree, but I can't see a way to let CMake do that. Anyone else have
any ideas? If you were on a *ix system you could FIND_PROGRAM a copy of
config.guess and parse its output. Yuk.
# Now here is my first big problem. CMake doesn't know how to handle
# any of these:
#add_executable (mini-os.gz mini-os.elf x86_64.o)
# I don't think ADD_EXECUTABLE is what you're looking for here.
# If you can set up the build steps with ADD_CUSTOM_COMMAND you should
# be able to add those with an ADD_CUSTOM_TARGET
'add_executable (mini-os.elf ....)' at least should work. The target
is a normal elf binary. The x86_64.o object file just doesn't tell
cmake enough to know how to link it. I figure it wants to know whether
this is C or C++ or some other language needing special flags. Once I
add some *.c file there or if I could teach cmake about *.S then it
should work.
# To teach CMake about *.S I believe you'd need 4 files:
# CMakeASMCompiler.cmake.in
# CMakeASMInformation.cmake
# CMakeDetermineASMCompiler.cmake
# CMakeTestASMCompiler.cmake
# There are similar ones for C, CXX and Java. You'd then be able to
# write:
PROJECT(MOOSE C ASM)
# Or whatever the list of languages you use is.
# How do I make a rule for assembler files? Doesn't seem to be preset.
ADD_CUSTOM_COMMAND (OUTPUT x86_64.o
COMMAND gcc -D__ASSEMBLY__ -Iinclude -Iinclude/x86
-Iinclude/x86/x86_64 -c x86_64.S -o x86_64.o
COMMENT Assembler pass)
# Or define my own linker script?
ADD_CUSTOM_COMMAND (OUTPUT mini-os.elf
COMMAND ld -N -T minios-x86_64.lds -m elf_x86_64 x86_64.o
-L. -lminios -o mini-os.elf
DEPENDS x86_64.o minios
COMMENT Link kernel into shape)
# And a rule to gzip the result?
ADD_CUSTOM_COMMAND (OUTPUT mini-os.gz
COMMAND gzip -f -9 -c mini-os.elf >mini-os.gz
DEPENDS mini-os.elf
COMMENT compress kernel)
# These look reasonable, apart from the fact that you should be looking
# for the executables with FIND_PROGRAM because not everyone will have
# the right versions at the front of the system path. Just allows a user
# override, that's all. Are they giving you a specific problem?
Just that they disapear when I don't have a ADD_CUSTOM_TARGET
depending on them. The rest is just taste. They look dirty.
# What else would you expect them to do? Without an ADD_CUSTOM_TARGET,
# there's no way to know when or why to run them.
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.)
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)
# 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.
# 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 >.
# -- Jack
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
