Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows support ? #252

Open
Salamandar opened this issue Jul 20, 2018 · 9 comments
Open

Windows support ? #252

Salamandar opened this issue Jul 20, 2018 · 9 comments

Comments

@Salamandar
Copy link

@Salamandar Salamandar commented Jul 20, 2018

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
@Jehan
Copy link

@Jehan Jehan commented Jul 21, 2018

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. :-/

@ximion
Copy link
Collaborator

@ximion ximion commented Jul 21, 2018

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?

@Jehan
Copy link

@Jehan Jehan commented Jul 21, 2018

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. :-)

@ximion
Copy link
Collaborator

@ximion ximion commented Jul 21, 2018

@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.

@Jehan
Copy link

@Jehan Jehan commented Jul 21, 2018

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
Copy link

@Jehan Jehan commented Jan 10, 2019

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
Copy link

@Jehan Jehan commented Jan 26, 2019

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.

@hughsie
Copy link
Owner

@hughsie hughsie commented Feb 6, 2019

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

@Jehan
Copy link

@Jehan Jehan commented Feb 6, 2019

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants