Doesn't build on Windows

[LRN]

There are multiple problems with building appstream on Windows with MinGW-w64:

• Includes <sys/utsname.h> (missing on Windows) unconditionally.
  • Should use ccompiler.has_header() to detect it at configure-time, then conf.set('HAVE_SYS_UTSNAME', result-of-the-check)
• Uses <fnmatch.h> (missing on Windows) for `fnmatch().
  • Should use <glib/gpattern.h> and g_pattern_match_simple(), or something along these lines.
• as_get_current_arch() uses utsname (see above) and needs a Windows-specific implementation.
  • A simple GetSystemInfo() call should do the trick (though be mindful of PROCESSOR_ARCHITECTURE_* constants, some of them are not in MinGW-w64 headers yet).
• directory_is_empty() uses opendir() & friends. Doesn't work with utf-8 filenames, and only works on Windows because MinGW has an implementation (so no MSVC compatibility).
  • Replace with g_dir_open() & friends.
• as_utils_is_root() uses unportable means of checking for administrative privileges (checks UID).
  • There's some code (see Solution #3) that you can re-use, although i would suggest getting rid of __try() & friends, as these don't work with MinGW.
• as-distro-extras.c uses symlink() (absent on Windows)
  • It's easy to approximate with CreateSymbolicLinkW() (Vista-or-later required - add_global_arguments ('-D_WIN32_WINNT=0x600', language : 'c')), with a bit of extra code for utf-8->utf-16 conversion (glib has that), though be sure to add SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag. Note that you also need a special flag to make a directory symlink, so this function works either on files only or on directories only, depending on the flags. Appstream seems to use symlink() only for files, and when it won't, the caller would surely know what is being linked, so the appropriate context information can be passed down.
• ascli-actions-mdata.c uses uint instead of gint (causes a warning)
• appstream-cli.c uses isatty(fileno (stdout)) - very problematic on Windows.
  • Use g_log_writer_supports_color (fileno (stdout)) instead.
• Meson builddefs add unconditional 'gio-unix-2.0' dependency
  • Make it conditional on host_machine.system() != 'windows'. No need for gio-win32-2.0 or anything in the else branch, AFAICS.
• Meson builddefs have bizarre include_directories(['/usr/include']).
  • Just remove that.
• as_distro_details_get_str() crashes because it can call g_key_file_get_string() with NULL key and id.
  • Check for priv->keyf != NULL && priv->id != NULL, return NULL if the check fails. Same goes for other places where priv->id or priv->keyf are used - add NULL checks.

[ximion]

AppStream/libappstream has not at all been designed to work on Windows, and I have no means to test/debug this properly (especially since I have no reason to attempt a Windows port).
However, patches to make this work would be welcome!

[LRN]

I can't fork on github and file a MR, since that would require me to enable non-free JS on github. If you're OK with patches-disguised-as-text-files (because github really wants me to fork and forbids attaching .patch files), i can attach these.

P.S. "Not been designed" is not entirely true. Appstream is distro-agnostic by definition, and that can be stretched to cover Windows as well.

P.P.S. That said, i have absolutely no clue who or why would want to use libappstream on Windows. But it can be built, so it should be!

[hughsie]

If it helps, I think the gimp people are building appstream-glib on Windows.

since that would require me to enable non-free JS on github

You know Windows and the WIN32 API is non-free, right?

But it can be built, so it should be

If you're willing to write the code... you can't expect @ximion to just do all that work.

[LRN]

If you're willing to write the code...

if you're OK with patches-disguised-as-text-files [snip], i can attach these.

[ximion]

You could also clone the repository to somewhere else and have me pull from there (I wouldn't mind patches as textfiles either though, as long as I can comment on them).
AppStream is distribution-agnostic, but it is designed for Linux distributions primarily and may be used by *BSD, if they want it. That's what it is tested on and what it is developed for.
What concerns me a bit is that you would port the library and tools "just because" - I don't consider this to be a long-term viable approach, because the code will inevitably become unbuildable on Windows again at some point if nobody actually uses in on Windows, and more importantly, if nobody would use it on Windows, we would have zero testing on that platform. If it compiles, it doesn't necessarily mean that everything also works as expected.

That said, if there is a benefit for someone and the patches to the code aren't too invasive, I don't mind merging such changes. Merging code that nobody uses though, is something I am wary about.

[Conan-Kudo]

I can't fork on github and file a MR, since that would require me to enable non-free JS on github. If you're OK with patches-disguised-as-text-files (because github really wants me to fork and forbids attaching .patch files), i can attach these.

@LRN You know you can do forking, pushing, and making pull requests entirely through GitHub's API? There's even a program for this called hub.