appstream-glib icon indicating copy to clipboard operation
appstream-glib copied to clipboard

Windows support ?

Open Salamandar opened this issue 6 years ago • 9 comments

Hi, appstream-glib currently relies on several linux-only components:

  • dependency('uuid') that is provided by libutil-linux/libutil-linux-dev on msys… And unavailable on mingw.
  • dependency('gio-unix')
  • header fnmatch.h

Salamandar avatar Jul 20 '18 23:07 Salamandar

Hi! I'd like to back a bit this request, since what Salamandar didn't specify, this is that we need this for GIMP. I don't really think AppStream metadata really needs to be platform specific. :-)

I tried to cross-build util-linux (as well as this other implementation which is apparently independent, whose website seems down though it can still be found on Fedora repos and archive.org) but failed so far. :-/

Jehan avatar Jul 21 '18 13:07 Jehan

Just out of curiosity, what does GIMP actually need appstream-glib for? Does it actually have to read AppStream metadata somewhere, and if so, why?

ximion avatar Jul 21 '18 13:07 ximion

Just out of curiosity, what does GIMP actually need appstream-glib for?

I am writing an extension management system (searching, (un)installing, updating extensions from within GIMP) for plug-ins, brushes and whatever data. The base of this is the metadata which a plug-in creator will write to describe the extension and its contents.

I could have used another format or even make our own metadata format, but thought it was smarter to just use AppStream since the format has everything we need and even a maintained library. :-)

Jehan avatar Jul 21 '18 13:07 Jehan

@Jehan That's pretty cool! As far as I can see, you will have a few options to achieve that:

  • Use appstream-glib: You should definitely disable the builder part when compiling on Windows, that should get rid of a great portion of dependencies. To cut down the rest though, asglib would need changes and I am not sure if those could be done without an API break. @hughsie knows more.
  • Use appstream: links: Just use the AppStream URL handler to launch the software center to install a missing dependency. That is likely the easiest way possible - at least on Linux - to install missing components, and means you don't need to implement any complext installation logic yourself. It's also easy to use for the user. See https://www.freedesktop.org/software/appstream/docs/sect-AppStream-Services-UrlHandler.html for details.
  • Use libappstream: The AppStream reference implementation purposefully build-depends only on GLib/GObject/GIR, libyaml, libxml2 and gperf. Therefore it's quite light on dependencies, however it has never been built on Windows to my knowledge, and makes Linux-specific assumptions for metadata pool paths. If you only use the AsMetadata class, it should be okay though. Guaranteeing Windows support is also not something I would like to do, because I can't properly test things on Windows.

Please keep in mind that appstream-glib and libappstream both can not be compiled with the MSVC compiler but need GCC or Clang due to their heavy dependence on __attribute__((cleanup)) , so if you have to compiler with Microsoft's compiler, there is no way to use any of the AppStream libraries.

ximion avatar Jul 21 '18 13:07 ximion

Use appstream: links

As you note, that's quite Linux-specific. We need something as cross-platform as possible, even though yes, it means I have to implement a bit of logics (but that's not that much logic anyway).

In any case, I want more logics that what is usually in software centers. For instance I will allow to disable an extension (without uninstalling it).

Use libappstream

Even though appstream-glib would be probably better as we already depend on glib, and it allows to use GIO files, etc. I guess using libappstream instead is a good idea if appstream-glib is not cross-platform on time. I'll have a look.

Please keep in mind that appstream-glib and libappstream both can not be compiled with the MSVC compiler but need GCC or Clang

I don't think that's a problem, at least not for me. But I don't want to talk for our packagers. In any case, I don't think most of GIMP or its dependencies is thought with MSVC in mind.

Jehan avatar Jul 21 '18 13:07 Jehan

For the record, I have ported appstream-glib to Win32 (actually I even ported libappstream first by mistake as I messed up which we were using!), but I am not making a pull request yet, because this is completely untested. It now cross-compiles for Windows as I replaced problematic parts with various Win32 API by reading docs, that's all I can say! I'm sure though that when I will test, some stuff will be wrong. :-P

I'll do a pull request when I will have actually tested. For the meantime, I just leave a note here: https://github.com/Jehan/appstream-glib/tree/wip/Jehan/win32-port

Jehan avatar Jan 10 '19 17:01 Jehan

Today I did a full cross-build of GIMP using this appstream-glib and ran it in a Windows 10 VM. GIMP runs fine and the extension management code (which uses appstream-glib) works too. Not sure any of my code uses any of the function which I had to touch up to make appstream-glib build for win32 though. So I'll probably do explicit test of these functions before I make a merge-request.

Jehan avatar Jan 26 '19 21:01 Jehan

I guess I'll wait for the PR then. Thanks.

hughsie avatar Feb 06 '19 13:02 hughsie

@hughsie I spent some hours today to review all my changes and fix what needs to be (basically I based my fixes on the unit tests, ensuring they all pass). So I opened #288 just now.

Happy reviewing!

Jehan avatar Feb 06 '19 18:02 Jehan