When generating config module for a shared library the config module could use the new ACME_INSTALL_TARGETS_XXX_DESTINATION variables to find the runtime component of the lib (so or dll)

//#acme namespace |<namespaces-with-double_colons>| { <C++ code> }
//#acme namespace |<namespaces-with-double_colons>| { | }

Example:

    //#acme namespace foo.bar { class Foo; }

expands to

    namespace foo { namespace bar { class Foo; }}

and

    //#acme namespace foo::bar {

expands to

    namespace foo { namespace bar {

and if foo.bar has the namespace alias foobar defined in the acme_find_package call, then

    //#acme namespace foobar }

expands to

    }}

with acme_find_package you can specify an ALIAS (and also a source NAMESPACE).
For legacy packages we need to define multiple NAMESPACES-ALIASES either in acme_find_package or better, acme_namespace_alias

When including multiple acme project in a superproject, it's a crucial problem with the traditional build system that the install step is performed after all subproject has been built. So if foo depends on bar, it won't find bar (or an outdated version) when foo is building since bar has not been installed yet.

We need to

• add INTERFACE_INCLUDE_DIRECTORIES, INTERFACE_COMPILE_DEFINITIONS, INTERFACE_LINK_LIBRARIES target properties to the library targets to help dependent projects to use them while they are not installed
• those properties will refer to the source tree and not the install location
• acme_find_package should look for a target with the same name and use that if exists
• because of the acme include header structure (dep projects always use #include "full/package/name/header.h" the whole feature can be supported only if
  • the dependent package's location in the superproject's dir is package path (company/foo/bar)
  • or we install it into a dot-separated dir below: company.foo.bar and rewrite the includes to use the dotted path (while processing the source files)
  • so when installing the public headers of a project we can also need to decide where to install them, into include/foo/bar or include/foo.bar. This could be determined automatically or by a variable (ACME_PUBLIC_HEADER_INSTALL_PREFIX=[FLAT|HIERARCHY]). The acme_find_package should be prepared for both and rewrite includes if needed.
• The include paths rewrites could be spared by providing a include path generator macro (CMake also supports this by directory property IMPLICIT_DEPENDS_INCLUDE_TRANSFORM)

Use case: building a library and it has test executables.
If we set the INTERFACE prop of the lib target then this will work:

add_executable(thetest thelib)

This is useful when we add files by globbing. Also a use case:

• during development, glob and save file list
• at a point instead of glob, load the files. This should also be supported by acme_add_files

when some components are required, other are not. In this case in the config module we need to look for only the components actually found.

When parsing source files (c/cpp) and an error or warning is detected, we should print line numbers.

FIND_PACKAGE_HANDLE_STANDARD_ARGS makes upper case prefixes so its very common that for a package to have XXX_FOUND + Xxx_FOUND + Xxx_INCLUDE_DIRS, and also Xxx_FOUND + XXX_INCLUDE_DIRS
just check for both upper and original case, use both, warn if ambiguous

projects (libraries) built withing superproject may be used by other subprojects during the build before they are installed
We need to delete installed files during the build to prevent finding them instead of the most current headers

Use the original package name as key (e.g. Boost/LibXml2) and a dictionary should return the actual prefix (Boost/LIBXML2)

appr var names: leading _ and prefixed with macro name/initials

In an ACME project's CMakeLists.txt we need to

• decide which headers (or other files) we need to install into include/
• where to install them below : there or into some subdir
• what include paths should be added to access the public files
  • when building the project
  • or when this project is a library in a superproject and the dependent project needs to access the public headers from the source tree (because the install step has not been done yet)

Current situation:

    add_public_header(<file> [DESTINATION <destdir> ...)

Suggestion 1.

    add_public_headers(
        [FILES <file> [<file> ...] [RELATIVE <dir>]]
        [GLOB|GLOB_RECURSE] <glob-expr> [RELATIVE dir]]
        [TAGGED RELATIVE dir]

If you omit RELATIVE then it defaults to the top-level dir of the corresponding file set.
Relative file paths will be interpreted relative to current source dir.
By default the files tagged as //#acme public header are interpreted relative to the current source dir, so for example a file ${CMAKE_CURRENT_SOURCE_DIR}/foo.h will be installed into include//foo.h.
With the TAGGED form you can override the RELATIVE property (base dir) of the tagged files.
The hierarchy will be kept below the RELATIVE dirs (base dirs)
The base dirs will be added to the include_directories.

Use cases:

• Add files tagged as //#acme public header (keeping their hierarchy)
  • relative to CMAKE_CURRENT_SOURCE_DIR (will be installed to include/)
  • or from CMAKE_CURRENT_SOURCE_DIR/include (will be installed to include/)
• Add non-tagged (generated) files from CMAKE_CURRENT_BINARY_DIR (or its subfolder), install to include/
• Add files from (specified by exact filenames or globbing, relative to a prefix in source tree, installed to include//rel-to-prefix/