This issue is an umbrella issue and a blocker for the alpha release. It aims to act as an audit to ensure that the mentioned APIs below are feature complete and not missing functionality (as this has on occasion caused me embarassment when I go to show something and realize that the code has been temporarily disabled due to a bug elsewhere)
Luckily, having this umbrella issue will allow us to also know what general documentation for a given section must be written.
APIs
Dict API
Some work is needed to also add the ability to deserialize an IXM file onto any set_property(<type>)
. This will let us deserialize IXM files into add_test calls as desired.
Find API
Target API
This API is still in flux and does not quite exist in a "stable" manner. The idea is to replace the target_XXX
commands such that we do not need to override them while also allowing custom user defined hooks without having to break existing APIs. No idea if this will actually work well. We'll leave this section blank as #18 is still open.
Project API
These are commands related to common project settings, such as options, features, and 'optional dependencies'. Currently the existing API/Project.cmake
file is an absolute mess. Better support is desperately needed :(
Logging API
The logging API is working fairly well. A few options should be dropped to work better with CMake's newer --log-level
settings, but otherwise it's going very well. One thing that is still needed is
- Knowing when to "cycle" a logging file (something that should be handled only on configure start, not after)
- Require JSONL support to be explicitly enabled via a cache variable. This speeds up logging tremendously per message.
- Better detection of when to print color output or not. If there was a way to detect if we're on the Windows Terminal vs a default cmd.exe or pwsh.exe instance, we should use that. This detection should be placed in the prelude file.
Otherwise, we'll leave this section blank for now.
Introspection API
This API is currently used internally for the invoke()
command. While dynamic command invocation is neat and all, its something that should be phased out within IXM. This means getting rid of the event API, which will be mentioned later in this issue. That said everything is working quite well, and is quite simple, though the inspect()
command itself needs some love as its quite a nightmare to view at the time of this writing:
macro (inspect)
foreach (@inspect:var ${ARGV})
set(CMAKE_MESSAGE_INDENT "${CMAKE_MESSAGE_INDENT}${\@inspect\:var}: ")
if (DEFINED ${\@inspect\:var})
list(LENGTH ${\@inspect\:var} @inspect:length)
if (@inspect:length GREATER 1)
string(JOIN " " ${\@inspect\:var} ${${\@inspect\:var}})
endif()
_message("${\@inspect\:var}: ${${\@inspect\:var}}")
else()
_message("${\@inspect\:var}: $<UNDEFINED>")
endif()
void(CMAKE_MESSAGE_INDENT @inspect:var @inspect:length @inspect:prefix)
endforeach()
endmacro()
Hopefully it can be cleaned up in time for the alpha release.
Event API
Because of its dynamic invocation internally, we need to get rid of this. It's not even used internally, except for the still in flux Target API. Mark it up as a failure that CMake is such a dumpster fire when it comes to actually usable concepts. :/
Import and Module API
This is kind of a mistake in hindsight. It's nice to do things like import(IXM::API::*)
, but at the same time only we currently use it, the behavior for it hides errors for includes, and it makes it difficult to know if a file is even being used when it might be 'optional' to begin with. Whether it exists in the alpha release or not depends on whether I have time to kill it now and I kind of hope I do.
That said, declaring a "MODULE_ROOT" isn't such a bad idea as it allows a better extension approach when adding additional libraries to support or extend IXM (such as adding tooling support or generation)
Generate API
This was basically butchered recently because of the additions made in CMake 3.16. Its still useful, as we can generate flex, bixon, protobuf (sort of... some work is needed to keep things nice and clean here because the cmake support for protobuf is a shitshow). The big point is that we can generate a response file from a target (not source files, because generator expression limitations), which makes generating source files from other tools easier! hooray!
But we still need an overhaul for this...
Fetch API
This is in DESPERATE need of an major overhaul. Current issues include
- No progress bar when enabled. This can be worked around, but requires some magic on our part
- No caching of multiple versions if a user desires. i.e., vendoring is always enabled and stored in the build directory. There is no reason why we can't keep the source directory in a central location (we do have some rudimentary
$XDG_DATA_HOME
support!) so that debug and release builds pull from the same location. With CMake 3.17 adding multi-config Ninja build support, this is important as it'll reduce pain for many users, while still allowing the vendoring of assets and better CI integration
- the custom reference syntax is nice, but a more explicit syntax would be nicer. I've experimented with it a bit, but am unsure how to proceed. A LOT OF WORK is needed to get this all setup :(
Additionally CLONE
should be enabled by default, and instead something like CACHE
or DOWNLOAD
should be an option for when you can download a package instead of just clone it via git or hg or svn or whatever.
Aspect API
I like it! It's been useful for setting certain values and keeping properties inheritable in a proper manner such that a top-level project is always in charge. However I'm unsure if users are going to enjoy it or not. Additionally, it's an important command and should be placed into API/Core.cmake
.
Console API
This is fine as is. The hard part is placing everything into the prelude and keeping it readable. I'm unsure how to proceed with this portion of it.
Builtin Blueprints
Coven
This is the "recommended" blueprint for new projects, as an upgrade path will be provided when the actual coven build system is released in a few years (yes, years... I'm a busy girl). A lot of work is needed here.
Brujeria
This one is much simpler, as it's ONLY used to generate a single add_library(MODULE)
per project, and is intended for use with the brujeria python library. The hard part of course is making sure folks have an update to date IXM instance when building from source, but we can add some CI tooling to help ensure that.
Final Notes
IXM is currently a loose collection of ideas that need to be locked down and finalized before the "stable alpha" release. We also have a large number of deprecated modules and files that have been kept around for historical reasons. These need to be removed ASAP.
This concludes the umbrella alpha release issue (for now).