Improve generated cmakelists

[arkena00]

Is your feature request related to a problem? Please describe.

Huge size of generated cmakelists

Describe the solution you'd like

Reduce the size and the number of targets

Describe alternatives you've considered

I don't know what's the use case of people generating cmakelists but when using it in an IDE, the size and the number of generated targets can really slow the IDE.

I'm not sure to understand why you can't use automoc, the Qt path is supposed to be handled by xmake so you just need to pass the resolved path to the find_package and then use automoc.

Anyway you can still reduce the size by using 2 variables for cl et moc commands parameters and avoiding generating mocs for files not using q_object macro

Additional context

😢

Let me know what you prefer and i will try to hide those targets, maybe with EXCLUDE_FROM_ALL

[arkena00]

set_target_properties(xtest PROPERTIES RUNTIME_OUTPUT_DIRECTORY "${CMAKE_SOURCE_DIR}/build/windows/x64/release")

Add the build type prefix for debug release etc ..

Example :

set_target_properties(xtest PROPERTIES RUNTIME_OUTPUT_DIRECTORY_RELEASE "${CMAKE_SOURCE_DIR}/build/windows/x64/release")
set_target_properties(xtest PROPERTIES RUNTIME_OUTPUT_DIRECTORY_DEBUG "${CMAKE_SOURCE_DIR}/build/windows/x64/debug")

Or remove it and let the user choose the output directory

[waruqi]

Huge size of generated cmakelists

It is because that ADD_CUSTOM_COMMAND and PRE_BUILD did not work as I expected, so we need use add_dependencies and fake target to support it.

see https://gitlab.kitware.com/cmake/cmake/-/issues/17802

xmake/xmake/plugins/project/cmake/cmakelists.lua

Lines 693 to 708 in a9cc2ad

	if suffix == "before" then
	-- ADD_CUSTOM_COMMAND and PRE_BUILD did not work as I expected,
	-- so we need use add_dependencies and fake target to support it.
	--
	-- @see https://gitlab.kitware.com/cmake/cmake/-/issues/17802
	--
	local key = target:name() .. "_" .. hash.uuid():split("-", {plain = true})[1]
	cmakelists:print("add_custom_command(OUTPUT output_%s", key)
	cmakelists:print(" COMMAND %s", command)
	cmakelists:print(" VERBATIM")
	cmakelists:print(")")
	cmakelists:print("add_custom_target(target_%s", key)
	cmakelists:print(" DEPENDS output_%s", key)
	cmakelists:print(")")
	cmakelists:print("add_dependencies(%s target_%s)", target:name(), key)
	else

If you have a better solution to this problem, you can reduce 90% targets at least.

[SirLynix]

We could use AUTOMOC at least for moc generation, and set AUTOMOC_EXECUTABLE so CMake doesn't have to find Qt by itself.

[arkena00]

AUTOMOC_PATH_PREFIX
AUTOMOC_MOC_OPTIONS
Yep you have what you need with that, same for AUTORCC

//

set_target_properties(xtest PROPERTIES RUNTIME_OUTPUT_DIRECTORY "${CMAKE_SOURCE_DIR}/build/windows/x64/release")

This breaks the paths in CLion because the output will be the same for all modes. For my use case i can just remove this generated line from the cmakelists, but if you need you can add those properties with the *_mode suffix

[waruqi]

This breaks the paths in CLion because the output will be the same for all modes. For my use case i can just remove this generated line from the cmakelists, but if you need you can add those properties with the *_mode suffix

I know there is a problem here, but supporting multiple mode switches at the same time would require a lot of code refactoring and a lot of detail consideration. So for the time being it is not supported.

In addition, we need to be very careful with many cache-related issues.

Currently, only the vs/vsxmake generators support them.

If you are interested, you can also open a pr and refer to the vs generator to improve it.

xmake/xmake/plugins/project/vstudio/impl/vs201x.lua

Lines 519 to 597 in 95b9be3

	for mode_idx, mode in ipairs(vsinfo.modes) do
	for arch_idx, arch in ipairs(vsinfo.archs) do
	-- trace
	print("checking for %s.%s ...", mode, arch)
	-- reload config, project and platform
	if mode ~= config.mode() or arch ~= config.arch() then
	-- modify config
	config.set("as", nil, {force = true}) -- force to re-check as for ml/ml64
	config.set("mode", mode, {readonly = true, force = true})
	config.set("arch", arch, {readonly = true, force = true})
	-- clear all options
	for _, opt in ipairs(project.options()) do
	opt:clear()
	end
	-- clear cache
	memcache.clear()
	localcache.clear("detect")
	localcache.clear("option")
	localcache.clear("package")
	localcache.clear("toolchain")
	-- check platform
	platform.load(config.plat(), arch):check()
	-- check project options
	project.check()
	-- install and update requires
	install_requires()
	-- config targets
	_config_targets()
	-- update config files
	generate_configfiles()
	generate_configheader()
	end
	-- ensure to enter project directory
	os.cd(project.directory())
	-- save targets
	for targetname, target in pairs(project.targets()) do
	-- make target with the given mode and arch
	targets[targetname] = targets[targetname] or {}
	local _target = targets[targetname]
	-- the vcxproj directory
	_target.project_dir = path.join(vsinfo.solution_dir, targetname)
	-- save c/c++ precompiled header
	_target.pcheader = target:pcheaderfile("c") -- header.h
	_target.pcxxheader = target:pcheaderfile("cxx") -- header.[hpp|inl]
	-- init target info
	_target.name = targetname
	_target.kind = target:kind()
	_target.scriptdir = target:scriptdir()
	_target.info = _target.info or {}
	table.insert(_target.info, _make_targetinfo(mode, arch, target, _target.project_dir))
	-- save all sourcefiles and headerfiles
	_target.sourcefiles = table.unique(table.join(_target.sourcefiles or {}, (target:sourcefiles())))
	_target.headerfiles = table.unique(table.join(_target.headerfiles or {}, (target:headerfiles())))
	-- save file groups
	_target.filegroups = target:get("filegroups")
	_target.filegroups_extraconf = target:extraconf("filegroups")
	-- make target headers
	_make_targetheaders(mode, arch, target, mode_idx == #vsinfo.modes and arch_idx == 2)
	end
	end

[arkena00]

but supporting multiple mode switches at the same time would require a lot of code refactoring and a lot of detail consideration

What about removing RUNTIME_OUTPUT_DIRECTORY from the cmakelists as a hotfix then ? And let cmake use the default path, that's just two lines to comment.

I don't know what people needs when generating cmakelists but for CLion, there is no problem using the default path, it will use the build dir which can be configured in CLion

[waruqi]

but supporting multiple mode switches at the same time would require a lot of code refactoring and a lot of detail consideration

What about removing RUNTIME_OUTPUT_DIRECTORY from the cmakelists as a hotfix then ? And let cmake use the default path, that's just two lines to comment.

I don't know what people needs when generating cmakelists but for CLion, there is no problem using the default path, it will use the build dir which can be configured in CLion

No, the generated output path must be exactly the same as the default configuration of xmake. All generators are consistent with xmake's output path.

But you can modify output path in your xmake.lua by yourself.

target("xxx")
    set_targetdir("$(buildir)")

[waruqi]

I have improved it and reduced much custom command target in cmakelists on cxxmodules branch.

#2641

[waruqi]

I have merged it now. It should work.