To allow users to understand what the "core" API calls for IXM are, each one should be located directly within the Modules/API directory. Currently the following commands do not meet this requirement:

• [x] dict
• [x] inspect
• [x] invoke
• [x] var (This name is unhelpful, and should be replaced)
• [x] upvar
• [x] genexp
• [x] glob (Perhaps this function should be removed altogether)
• [x] import
• [x] module
• [x] blueprint
• [x] log
• [x] parse
• [x] print
• [x] success
• [x] failure
• [x] global
• [x] internal
• [x] cache

Feature Request

Since I can't open an issue to ask a question, I had to classify it as an enhancement.

It would be awesome to not have to write by hand an export file for CMake libraries. The information is already provided in the CMakeLists.txt and a common pattern is to then go repeat the dependencies in the exports file.

What is the current behavior?

Unsure if it exists.

Why should this be changed or added?

Because it removes useless repetition.

How would you implement this?

By introspecting the properties of the targets defined under a project.

Additional Information

Are you willing to work on this yourself? Yes How urgent is it to have this feature? Not urgent. Is this feature request possibly out of scope for IXM? Not sure.

As wonderful as Rust's cargo is, not all projects are mono-lingual. It would be extremely great if a C++ or C project could link to an existing Rust project. Even better, being able to build a rust program that is then used for an add_custom_command or add_custom_target would be fantastic!

• [ ] Toolchain Detection
• [ ] Compiling Native Libraries
• [ ] Cross Compiling Support
• [ ] C and C++ integration
• [ ] Some form of dependency tracking

Currently, when CMake is cross compiling, it sets CMAKE_CROSS_COMPILING to TRUE. This also ends up meaning we can't compile any tools for code generation or otherwise when cross compiling. This is a huge limitation. However, there is a workaround and we can wrap it up into a special add_tool() command.

This command will perform the following steps when CMAKE_CROSS_COMPILING is ON

• Get the current list of enabled languages.
• For each language we
  • unset() certain variables in the current function scope.
  • set() the current CMAKE_SYSTEM_NAME into a temporary variable
  • set() the CMAKE_HOST_SYSTEM_NAME to CMAKE_SYSTEM_NAME
  • set(CMAKE_PLATFORM_INFO_DIR) to some predetermined directory
  • include(CMakeDetermine<LANG>Compiler)
  • `include(${CMAKE_PLATFORM_INFO_DIR}/CMakeCompiler.cmake)
  • set() host versions of variables
  • Set variables onto a dict() and save to disk with some sort of hash
• Call try_compile(PROJECT) with flags that are stored in said dict() (We cannot use generator expressions 😞). The project can either be the current one, or a separate one altogether.
• Call add_executable(name IMPORTED) and set the path to the given target.

The above is just the tip of the iceberg. There are many MANY things that need to be taken into account, such as, but not limited to:

• FetchContent locations
• System Dependencies
• Variables set by toolchain files

This is going to be a big feature, but it is EXTREMELY useful. That said, it's low priority until everything else is stable.

SDL2 is a lovely library, but the default FindSDL2.cmake files that are out there leave a lot to be desired. There's no reason we can't provide a file to help people along the way. It should also provide support for finding the various SDL2 components, such as TTF, image, net, mixer, etc.

AppImage is a pretty incredible tool and makes distribution of applications an absolute breeze compared to other forms of installation. However, CPack does not support generating an AppImage as a packaging format. It should! And it's doable.

This is now possible because we generate a bootstrap script that pulls IXM down via git behind the scenes so that it will automatically update as needed. This causes TONS of incorrect output and lots of failure. For example:

1. Color output doesn't work (but does if IXM is manually set on the command line or is used instead of the bootstrap script)
2. aspect() calls fail (due to how they are implemented)
3. Just a full cascade of errors I wasn't expecting.

This NEEDS to be resolved before launch.

Due to issues brought on by CMake 3.16's support for Unity builds and precompiled header support, we can't keep the IXM implementation of these around. They are, unfortunately, incompatible and will break when moving between CMake versions. Thus, sadly, 3.16 will have to be the minimum version for IXM's initial alpha release :(

CMake currently has a bunch of executable/shell operations builtin available via execute_process(COMMAND ${CMAKE_COMMAND} -E <command>)

If this were abstracted, we could do some cooler things like task(ECHO_APPEND args...). This wouldn't allow us to have "futures" as it were, but it would be nice so that we could at least take advantage of the cross platform commands builtin into CMake.

Whether this command is called task(), shell(), or even just cmake() is still TBD and needs some investigation into what feels most ergonomic.

If we could also somehow support pipelines, that would be killer :)

Writing emoji in build files is usually a red flag (if only that were an actual emoji...)

CMake does not provide a proper mechanism for read only properties, thus we need to discourage users overwriting them in their build files. CMake is also byte safe, so we should be able to use emoji without issue.

Current list of properties to place under emoji:

• [ ] attribute() subcommands (emoji TBD)
• [ ] Anything where we need to manually call get_property internally. (🔍 into what this entails...)
• [ ] All IXM commands should be placed into this so that they can easily be restored if necessary.
• [ ] Properties we keep track of

Due to the recent removal of the experimental property command (which wasn't even implemented), we are still in need of a custom define_property to

1. Keep track of defined properties (for the target_copy_properties command)
2. Make defining properties much easier
3. Allowing us to write some documentation in the source code before it is added to the documentation repository.