Issue with NASM order of commands in cmake included

[AlexMitchellMus]

https://gitlab.kitware.com/cmake/cmake/-/issues/19751

Apparently there is an issue with CMake and NASM command order with MSVC.

I fixed this by added a custom NASM invocation, and not using the default one in CMake.

[dmikushin]

Hi @AlexMitchellMus , please share your fix to make it more clear what happens.

[AlexMitchellMus]

I'm still battling a few things, but something like this custom command at least stopped the NASM error code 1:
** ResEmbed.cmake **

	if (USE_NASM AND MSVC)
		find_program(NASM_PATH nasm REQUIRED)
		set(EMBED_FILE_OBJ "${CMAKE_CURRENT_BINARY_DIR}/${RES_EMBED_NAME}.obj")
		if(CMAKE_SIZEOF_VOID_P EQUAL 8)
			set(NASM_OBJ_FORMAT "win64")
		else()
			set(NASM_OBJ_FORMAT "win32")
		endif()
		add_custom_command(
				OUTPUT "${EMBED_FILE_OBJ}"
				COMMAND "${NASM_PATH}" -f ${NASM_OBJ_FORMAT} -o "${EMBED_FILE_OBJ}" "${EMBED_FILE_PATH}"
				DEPENDS "${EMBED_FILE_PATH}"
				COMMENT "Assembling ${EMBED_FILE_PATH} to ${EMBED_FILE_OBJ} with NASM (${NASM_OBJ_FORMAT})"
				VERBATIM
		)
		target_sources(${RES_EMBED_TARGET} PRIVATE "${EMBED_FILE_OBJ}")
	else()
		target_sources(${RES_EMBED_TARGET} PRIVATE "${EMBED_FILE_PATH}")
	endif()

Hopefully I can push the full fix soonish. Thanks for the quick reply!

EDIT:

Here is the original error emitted from c78af63:

C:\Program Files\JetBrains\CLion 2023.3.3\bin\cmake\win\x64\share\cmake-3.31\Templates\MSBuild\nasm.targets(33,5): error MSB3721: The command ""C:/Users/alexw/scoop/shims/nasm.exe" -o "PatchformSDK_IconFontPlugPatch.dir\Debug\IconFontPlugPatch.obj" -fwin32 -D"WIN32" -D"_WINDOWS" -D"CMAKE_INTDIR="Debug"" -f "C:\Users\alexw\Documents\github\audiograph\cmake-build-debug-visual-studio\IconFontPlugPatch.nasm"" exited with code 1. [C:\Users\alexw\Documents\github\audiograph\cmake-build-debug-visual-studio\PatchformSDK_IconFontPlugPatch.vcxproj]
  Embedding file C:/Users/alexw/Documents/github/audiograph/Assets/Fonts/Inter_18pt-Regular.ttf content identified by key Inter_18pt_Regular
  Building Custom Rule C:/Users/alexw/Documents/github/audiograph/CMakeLists.txt
  Assembling Inter_18pt_Regular.nasm

System NASM:

NASM version 2.16.03 compiled on Apr 17 2024

[dmikushin]

Respectfully, I think your approach is deemed to give you a lot of pain, because it hardcodes many things.

Let's get back to the original issue. Do you agree that the issue is that NASM command line is spoiled with some command line options it has no support for?

If yes - then here is what you could do: create a NASM.exe wrapper (e.g. in Python), which strips all unsupported command line flags from sys.argv and calls the real NASM with a proper set of flags. LLM can do such wrapper for you in 10 seconds.

[AlexMitchellMus]

Let's get back to the original issue. Do you agree that the issue is that NASM command line is spoiled with some command line options it has no support for?

Yes this is what the CMake issue 19751 seems to imply, and running NASM from terminal does work correctly with correct command order.

If yes - then here is what you could do: create a NASM.exe wrapper (e.g. in Python), which strips all unsupported command line flags from sys.argv and calls the real NASM with a proper set of flags. LLM can do such wrapper for you in 10 seconds.

Would this not be something that should be in res_embed? As it's intended to work for MSVC also?

[dmikushin]

MSVC worked well some time ago, but NASM is not a very much beloved citizen in CMake, I won't be surprised it's untested and went broken at some point. Fundamentally, the problem is how the compiler options are propagated under the hood, when MSVC so-called "toolchain file" is activated within CMake. This "toolchain file" logic is generally not customize-able by user's CMake script. Custom commands are even worse: it's gonna be an ugly hack. I hope this brings in some context.

So, possible solutions are:

1. Create our own "toolchain file" for MSVC and ask to use it instead of the officially broken one. That's a no go either: nobody would bother, it's a difficult extra step. Things for users must work out of the box.
2. Take CMake's bugs as granted and wrap NASM into something that CMake could work with. Then add wrapper into PATH, so that it shadows the official executable. This is still an extra step, but it's more robust.

[AlexMitchellMus]

I suppose the wrapper is best, but even when if maybe fixed, should still function.

[AlexMitchellMus]

Sorry, jumped to close. Feel free to close if you don't want to track this here. :-)