GBFS Suggestions
crispyross opened this issue · comments
-
It seems to me that gba_add_gbfs_target creates a filesystem containing all files, while gba_target_add_gbfs_dependency converts a single given file to a .s file.
It is kind of confusing to differentiate them. I suggest renaming gba_target_add_gbfs_dependency to something like "gba_target_add_resource_as_asm" since (1) it isn't directly related to a filesystem; it just uses gbfs tools, and (2) it tells you that it makes a ".s" file you can use. -
In a few places (e.g. gba_add_gbfs_target), you use add_custom_target to specify how to build a given file. The CMake documentation says the following:
The target has no output file and is always considered out of date even if the commands try to create a file with the name of the target. Use the add_custom_command() command to generate a file with dependencies.
A better way to do this is to use add_custom_command to specify how to build a given file, then add a target with add_custom_target that depends on whatever file is built using add_custom_command.
- Is embedding the gbfs into the rom implemented? I didn't see how to do it.
If it helps, here is how I build the FS image and embed it in the rom:
set(FS_PATH "${CMAKE_CURRENT_BINARY_DIR}/fs.gbfs")
set(FS_CONTENTS test.txt)
add_custom_command(OUTPUT ${FS_PATH}
COMMAND "${GBA_TOOLCHAIN_GBFS}" "${FS_PATH}" ${FS_CONTENTS}
WORKING_DIRECTORY "${CMAKE_SOURCE_DIR}"
DEPENDS ${ARGN}
COMMENT "Building filesystem"
VERBATIM
)
add_custom_target(filesystem DEPENDS ${FS_PATH})
add_dependencies(${PROJECT_NAME} filesystem)
...
add_custom_command(TARGET ${CMAKE_PROJECT_NAME}
POST_BUILD
# Copy + strip to binary-only
COMMAND "${CMAKE_OBJCOPY}" -O binary ${CMAKE_PROJECT_NAME}.elf ${CMAKE_PROJECT_NAME}.gba
# Pad to nearest 256 byte (needed for gbfs)
COMMAND "${GBA_TOOLCHAIN_TOOLS}/gbfs/tools/padbin.exe" 256 "${CMAKE_PROJECT_NAME}.gba"
# Append FS to binary (non-portable; needs CMake 3.18)
COMMAND ${CMAKE_COMMAND} -E cat fs.gbfs >> ${CMAKE_PROJECT_NAME}.gba
# Fix header
COMMAND "${GBA_TOOLCHAIN_GBAFIX}" "${CMAKE_PROJECT_NAME}.gba" "-t${ROM_TITLE}" "-c${ROM_GAME_CODE}" "-m${ROM_MAKER_CODE}" "-r${ROM_VERSION}"
WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}"
VERBATIM
)
I'm also not 100% happy with the current scheme.
The intention was to mirror CMake's add_executable
/add_library
with gba_add_gbfs_target
, but I think the use of the word "target" is a mistake here (taken from add_custom_target
). Perhaps just gba_add_gbfs
would be more obvious.
I can see where it's fallen short of that original intention. gba_add_gbfs
should instead create the library project, which would then be linkable by the normal CMake add_dependencies
.
Embedding in ROM is not implemented but it is something I want to do, I just haven't had the time to sit down and figure it out. Perhaps really all we need is a generic "pad and concat" command that's not gbfs specific.
Whoops, I didn't see the wiki. Things make a lot more sense now.
I've now implemented some CMake functions for padding a ROM and appending a GBFS file. The GBFS wiki page has more details.
gba_target_object_copy
gains an optional final parameter that is "padding boundary", for GBFS this should be 256 to pad to the default 256 boundary that GBFS expects.
gba_target_append_gbfs
is used for appending a gbfs target to a given file.
# Object copy with 256 byte boundary padding
gba_target_object_copy( my_target debug.elf rom.gba 256 )
# Create GBFS target
gba_add_gbfs_target( data.gbfs test.txt )
# Append GBFS target to rom.gba
gba_target_append_gbfs( my_target data.gbfs rom.gba )