Use path library for path manipulation

[ddalcino]

Fix #259.

Currently, this action relies heavily on string manipulation techniques to compose paths. This approach is prone to error, particularly in the context of Windows and inconsistent use of native path delimiters. This PR uses the standard Node path library to manipulate paths.

• Link to test run that replicates Bad QT_ROOT_DIR on Windows #259, using the install directory / and test runner windows-latest: https://github.com/ddalcino/install-qt-action/actions/runs/11786060831/job/32828603078#step:9:1
  Note the broken environment variables:

  IQTA_TOOLS: \\Qt\Tools\
  QT_ROOT_DIR: D:\Qt\6.7.0\msvc2019_64\bin\qmake.exe
  QT_PLUGIN_PATH: D:\Qt\6.7.0\msvc2019_64\bin\qmake.exe\plugins
  QML2_IMPORT_PATH: D:\Qt\6.7.0\msvc2019_64\bin\qmake.exe\qml
  

• Link to failing test run that explicitly checks the QT_ROOT_DIR variable: https://github.com/ddalcino/install-qt-action/actions/runs/11786135722/job/32828835488#step:8:1
• Link to passing test run, with environment identical to the failing runs, after the fix is applied: https://github.com/ddalcino/install-qt-action/actions/runs/11786675815/job/32830453747#step:8:1
  Note the fixed environment variables:

  IQTA_TOOLS: \Qt\Tools
  QT_ROOT_DIR: D:\Qt\6.7.0\msvc2019_64
  QT_PLUGIN_PATH: D:\Qt\6.7.0\msvc2019_64\plugins
  QML2_IMPORT_PATH: D:\Qt\6.7.0\msvc2019_64\qml
  

• Since 485d851 (use path.resolve instead of path.join), IQTA_TOOLS now has a drive letter: https://github.com/jurplel/install-qt-action/actions/runs/11788985029/job/32836995662?pr=266#step:8:1

  IQTA_TOOLS: D:\Qt\Tools
  QT_ROOT_DIR: D:\Qt\6.7.0\msvc2019_64
  QT_PLUGIN_PATH: D:\Qt\6.7.0\msvc2019_64\plugins
  QML2_IMPORT_PATH: D:\Qt\6.7.0\msvc2019_64\qml
  

[p0358]

This is definitely a big improvement and the right path. But I can't help but point out that passing output of path.join to nativePath aka path.normalize is pretty redundant now, since the output of path.join is already normalized. Note that this is not the same as path.resolve for example, but that one is not used...

Btw if poking at paths already, I think that this: const nativePath = process.platform === "win32" ? path.win32.normalize : path.normalize; is also redundant. Afaik Path API is gonna already behave with win32 behavior on win32 platform, I think this path.win32 implementations are explicitly only exposed if win32-specific behavior is desired for example during tests, otherwise it's kinda unnecessary, while making it a bit more cryptic what "nativePath" is, compared to just using path.normalize directly...

[jurplel]

If there's still value in unit testing feel free to pull in the jurplel/fix-qt-root-dir changes. It looks like it is covered in CI now, though.

Looks like the failed test is just flakiness?

[ddalcino]

If there's still value in unit testing feel free to pull in the jurplel/fix-qt-root-dir changes. It looks like it is covered in CI now, though.

I think unit testing is a really good idea, but I'd like to keep that separate from this PR for now.

Looks like the failed test is just flakiness?

The failed test does not appear related to the changes in this PR. Relevant code:

install-qt-action/.github/workflows/test.yml

Lines 138 to 144 in 09d1e79

	if ([version]$env:QT_VERSION -ge [version]"6.5.3") {
	# GitHub macOS 13/14 runners use Xcode 15.0.x by default which has a known linker issue causing crashes if the artifact is run on macOS <= 12
	sudo xcode-select --switch /Applications/Xcode_15.2.app
	} else {
	# Keep older Qt versions on Xcode 14 due to concern over QTBUG-117484
	sudo xcode-select --switch /Applications/Xcode_14.3.1.app
	}

The failed runs indicate that on some MacOS test runners, /Applications/Xcode_14.3.1.app does not exist:

xcode-select: error: invalid developer directory '/Applications/Xcode_14.3.1.app'

Maybe we could get around it with a glob star, like sudo xcode-select --switch /Applications/Xcode_14.*.app? That could get messy if it picks the wrong one, or the glob star returns multiple apps.

According to the bug report, this was fixed in Qt 6.5.3, so maybe the fix is no longer needed? [edit] no, that doesn't work for older versions of Qt ...

[jdpurcell]

That Xcode failure is related to actions/runner-images#10703 and I don't think it's possible to build with Qt < 6.5.3 on GitHub Actions with the newer runners (macOS 14/15) anymore; only macOS 13 and the soon-to-be-retired macOS 12 runners.