Doesn't build on Windows #231
Comments
|
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). |
|
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 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! |
|
If it helps, I think the gimp people are building appstream-glib on Windows.
You know Windows and the WIN32 API is non-free, right?
If you're willing to write the code... you can't expect @ximion to just do all that work. |
|
|
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). 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. |
@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 |
Now just |
Those are not the same at all though... (unless paired with a fork() and no other options)
That will likely need a Windows-specific implementation to get details about the Windows OS... |
|
does this fix this issue? #510 |
|
Can't pass the compilation with default options on Windows(MSYS2). Disable the |
|
one of the problems is hardcodig passing rebuilding now... let's see |
|
Are manual pages a useful thing to have on Windows? |
|
not for me, i just want to build libadwaita, but i'm sure MSYS2 would like to have manpages like every other software it packages |
|
MSYS build succeeded for me after skipping docs and disabling stemming as mentioned above PKGBUILD file posted here: msys2/MINGW-packages#17448 (comment) |
In that case I would really like to keep them default-enabled. |
|
@ximion re stemming: libstemmer and snowball are already packaged in MSYS2 so they are usable: https://packages.msys2.org/package/mingw-w64-ucrt-x86_64-libstemmer?repo=ucrt64 the only problem is the meson config using a hardcoded include dir that doesn't exist on MSYS2 systems (iirc it's using the standard include dir from meson should fix it: |
This will fail horribly on Linux systems where you build for a prefix that isn't |
|
how about this then? although i believe the best course of action is to add a meson option to explicitly specify where to look for it, defaulting to diff --git a/meson.build b/meson.build
index 0b5face2..2b738f41 100644
--- a/meson.build
+++ b/meson.build
@@ -141,6 +141,14 @@ endif
add_project_arguments('-DAS_COMPILATION', language: 'c')
+#
+# Modules
+#
+fs = import('fs')
+glib = import('gnome')
+i18n = import('i18n')
+pkgc = import('pkgconfig')
+
#
# Dependencies
#
@@ -164,27 +172,24 @@ endif
stemmer_inc_dirs = include_directories()
if get_option('stemming')
stemmer_lib = cc.find_library('stemmer', required: true)
- stemmer_inc_dirs = include_directories(['/usr/include'])
- if not cc.has_header('libstemmer.h')
- if cc.has_header('libstemmer/libstemmer.h')
- stemmer_inc_dirs = include_directories('/usr/include/libstemmer')
- else
- error('Unable to find Snowball header "libstemmer.h". Please ensure libstemmer/Snowball is installed properly in order to continue.')
- endif
+ stemmer_check_inc_dirs = [
+ '/usr/include', '/usr/include/libstemmer', get_option('prefix') / get_option('includedir')]
+ found = false
+ foreach stemmer_check_inc_dir : stemmer_check_inc_dirs
+ if fs.is_dir(stemmer_check_inc_dir) and cc.has_header('libstemmer.h', include_directories: include_directories(stemmer_check_inc_dir))
+ stemmer_inc_dirs = include_directories(stemmer_check_inc_dir)
+ message('Found "libstemmer.h" in ' + stemmer_check_inc_dir)
+ found = true
+ endif
+ endforeach
+ if not found
+ error('Unable to find Snowball header "libstemmer.h". Please ensure libstemmer/Snowball is installed properly in order to continue.')
endif
endif
# use gperf for faster string -> enum matching
gperf = find_program('gperf')
-#
-# Modules
-#
-fs = import('fs')
-glib = import('gnome')
-i18n = import('i18n')
-pkgc = import('pkgconfig')
-
#
# Directories
# |
|
this is how it fails with docs btw. it also fails on mac with the same error: |
Your system is missing docbook schemas. On Debian, they are in the docbook-xsl package, I have no idea how they can be installed on Mac or Windows, but given that it's just data, that shouldn't be too hard. https://packages.debian.org/sid/docbook-xsl |
|
For building AppStream with MSVC, the dependency on libxmlb is also a blocker since it uses g_autoptr which isn't supported: hughsie/libxmlb#150 |
|
Well, Appstream itself uses g_autptr everywhere, so I think building with MSVC is a no-go. GCC or Clang are the way to go on Windows, I'm afraid... |
|
At this point, appstream builds on cross-compiling MinGW at least, but some tests fail in Wine:
I've opened #687 fixing the first two. |
Oh, actually looking at it closer, a lot more tests fail here. They just aren't run since it stopped after the first one. |
There are multiple problems with building appstream on Windows with MinGW-w64:
<sys/utsname.h>(missing on Windows) unconditionally.ccompiler.has_header()to detect it at configure-time, thenconf.set('HAVE_SYS_UTSNAME', result-of-the-check)<fnmatch.h>(missing on Windows) for `fnmatch().<glib/gpattern.h>andg_pattern_match_simple(), or something along these lines.as_get_current_arch()uses utsname (see above) and needs a Windows-specific implementation.GetSystemInfo()call should do the trick (though be mindful ofPROCESSOR_ARCHITECTURE_*constants, some of them are not in MinGW-w64 headers yet).directory_is_empty()usesopendir()& friends. Doesn't work with utf-8 filenames, and only works on Windows because MinGW has an implementation (so no MSVC compatibility).g_dir_open()& friends.as_utils_is_root()uses unportable means of checking for administrative privileges (checks UID).__try()& friends, as these don't work with MinGW.as-distro-extras.cusessymlink()(absent on Windows)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 addSYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATEflag. 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 usesymlink()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.cusesuintinstead ofgint(causes a warning)appstream-cli.cusesisatty(fileno (stdout))- very problematic on Windows.g_log_writer_supports_color (fileno (stdout))instead.'gio-unix-2.0'dependencyhost_machine.system() != 'windows'. No need forgio-win32-2.0or anything in theelsebranch, AFAICS.include_directories(['/usr/include']).as_distro_details_get_str()crashes because it can callg_key_file_get_string()with NULL key and id.priv->keyf != NULL && priv->id != NULL, returnNULLif the check fails. Same goes for other places wherepriv->idorpriv->keyfare used - addNULLchecks.The text was updated successfully, but these errors were encountered: