Install VcPkg/Pkg-Config depending on target env

[filips123]

Although #39 was merged, Cargo.toml still required VcPkg on Windows, regardless of used toolchain. This meant that when someone tried to build compress-tools on windows-gnu, build script failed because it wasn't able to find pkg-config module.

This PR updates Cargo.toml to require either VcPkg or Pkg-Config depending on target env, just like build.rs since #39. It also updates docs and readme to indicate this.

[coveralls]

Pull Request Test Coverage Report for Build 810866131

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.5%) to 85.302%

---

Totals
Change from base Build 797784751:	0.5%
Covered Lines:	325
Relevant Lines:	381

---

💛 - Coveralls

[otavio]

@filips123 the change is good. Could you add a note on the CHANGES.md file and squash all commits?

[otavio]

and ... as you're involved in Windows GNU support, maybe you could prepare another PR adding a CI check for it?

[filips123]

Could you add a note on the CHANGES.md file and squash all commits?

Sure.

maybe you could prepare another PR adding a CI check for it?

I will probably try next week.

[filips123]

I added CI check for Windows GNU. Most tests are passing, but there is a segmentation fault (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION) while running integration test: https://github.com/filips123/compress-tools-rs/runs/2544416808#step:10:129

I think it's caused by uncompress_to_dir_with_utf8_pathname. And it happens at CStr::from_ptr(ffi::archive_entry_pathname(entry)) in https://github.com/OSSystems/compress-tools-rs/blob/master/src/lib.rs#L217 (specifically, when calling CStr::from_ptr).

[otavio]

It is likely to be the case. For it to run a proper locale must be in use. Try setting LC_ALL=en_US.UTF-8 as environment.

[filips123]

Unfortunately that didn't help.

[otavio]

@filips123 this is indeed quite hard to figure out without a proper environment to try it. The code involved in this is:

compress-tools-rs/src/ffi/locale.rs

Lines 50 to 91 in 6eaf5af

	#[cfg(windows)]
	mod inner {
	extern "C" {
	fn _configthreadlocale(arg1: std::os::raw::c_int) -> std::os::raw::c_int;
	}
	const _ENABLE_PER_THREAD_LOCALE: std::os::raw::c_int = 1;
	pub(crate) struct UTF8LocaleGuard {
	save: Option<std::ffi::CString>,
	save_thread_config: ::std::os::raw::c_int,
	}
	impl UTF8LocaleGuard {
	pub(crate) fn new() -> Self {
	let locale = b".UTF-8\0";
	let (save, save_thread_config) = {
	let old_locale = unsafe { libc::setlocale(libc::LC_CTYPE, std::ptr::null()) };
	(
	if old_locale.is_null() {
	None
	} else {
	Some(unsafe { std::ffi::CStr::from_ptr(old_locale) }.to_owned())
	},
	unsafe { _configthreadlocale(0) },
	)
	};
	unsafe {
	_configthreadlocale(_ENABLE_PER_THREAD_LOCALE);
	libc::setlocale(
	libc::LC_CTYPE,
	std::ffi::CStr::from_bytes_with_nul_unchecked(locale).as_ptr(),
	)
	};
	Self {
	save,
	save_thread_config,
	}
	}
	}

Please see if you can reproduce it on your Windows machine.

[filips123]

Yes, I can reproduce it.

[otavio]

So we'll need to figure out if the MSVC and GNU Windows support use the same schema for locale. I have no idea.