On Wed, 25 Jun 2025, Jon Turney wrote: > On 25/06/2025 20:52, Jeremy Drake via Cygwin-developers wrote: > > I would like to add tests of invoking non-Cygwin processes using > > posix_spawn and making sure their stdin/out/err and cwd are as expected. > > I see that there is a mingw directory for building with the cross-mingw > > compiler, and I could make a test child process built through that which > > uses GetFileInformationByHandleEx and GetCurrentDirectoryW.
This turned out to be more complicated than I expected, GetFileInformationByHandleEx(FileNameInfo) sucks badly, and seems to only actually work for regular files. Which is probably why Cygwin uses NtQueryObject(ObjectNameInformation) instead, which I switched to. This has the downside of giving NT native paths (\Device\HarddiskVolumeN\path). So then I needed to dynamically load cygwin1.dll to be able to use cygwin_internal(CW_MAP_DRIVE_MAP) (and the alloc and free) to translate the path. This all seems to work as I'd hope though. > > Can I be assured that when the winsup.api tests run that the mingw tests > > have already been built, or do I need some sort of dependency declared in > > the Makefile.am? > > Interesting question. Hmm... not sure how that works for the existing MinGW > executable, at the moment. > > I think this is already taken care of by the fact that 'check' depends on > 'all' (which in turn depends on 'all' in SUBDIRS). > > If not, I'm not sure how that precise dependency could be expressed (given > that those seem to have to live in a different Makefile.am to use a different > compiler) > > > How should the winsup.api test find the mingw test exe? > > Should I figure out what the cwd of the test run from the testsuite is and > > just use a relative path? dladdr an address in the exe and use the > > returned path to the exe to construct a path to the mingw exe? > > It would be fine to set an env var in the Makefile.am and use that to locate > the executable (as is currently done with cygrun=$(builddir)/mingw/cygrun) (or > I guess that could be generalized to an env var which points to the built > mingw executables directory) > > Or I guess all that could be copied into $runtime_root, which we arrange to be > on the PATH? > > But make you don't want to do that to make standalone running easier? I could see using an env var if set, and falling back to something likely to work when run standalone if not.
