intel/fastuidraw

Static Build

Closed this issue · 21 comments

r0l1 commented

A make target for static library builds would be great!

The main issue for a static build of FastUIDraw is how shader sources are included. The gist of it is that for each shader source, a C++ source file is generated of the form:

#include <fastuidraw/util/static_resource.hpp>
namespace {
const uint8_t values[] = { .... , 0 }
fastuidraw::static_resource R("NAME", fastuidraw::c_array<const uint8_t>(values, sizeof(values)));
}

where the content of values[] is the ascii codes of the shader source file and "NAME" is the filename without the full path.

The issue is that the ctor of R is what adds the entry to a global std::map<> holding the resources. With a static library (i.e. a libFastUIDraw.a made with ar), the ctor of R is never called. The way out of this is that I need to make a routine that references the object and that routine must be called; i.e. some kind of init function. Then all those init function would need to be get called, (by a global init function) which must then be stashed somewhere to get automatically called or the application must call it.

In addition, libFastUIDraw also has a number of dependencies (namely libstdc and freetype) which also complicates making a static library.

What is the use-case you have in mind for a static library build?

r0l1 commented

Thanks for the detailed explanation. I am working on a new UI concept, which should merge the worlds of native UIs and the web. I don't like our current web standards, its complexity and all those security issues. Firefox alone has more lines of code than the linux kernel..

I needed a simple UI library for a project and I stumbled about many issues... Here is a great write-up about the problem. I am a big fan of Qt's QML and I think, that the web has to be reinvented from the ground up. A simple and powerful rendering backend (canvas engine) combined with a safe programming language (golang) and a user interface markup language (QML-like). The rendering engine runs within a container sandbox and is piped with the help of wayland to the host. A transparent communication protocol allows to render the UI on remote hosts and this opens the doors for distributed apps running simultaneous on multiple systems...

Right now it's just a concept and the project is still in a very early stage. I am planing to write-up all the ideas and to release the initial code to github. It's just a hobby project...

The canvas engine uses SDL2 and fastuidraw. Currently I am working on a golang wrapper around the required fastuidraw methods... Golang apps are normally statically linked and that's why I would like to build a static fastuidraw library.

The ctor of R should be called, if the static library is linked with:

-Wl,--whole-archive ${FASTUIDRAW_LIB} -Wl,--no-whole-archive

should merge the worlds of native UIs and the web

Check my Sciter then. That's exactly it - HTML/CSS but embeddable UI engine - single library less than 5mb.

Yet it has GO integration: https://github.com/sciter-sdk/go-sciter

r0l1 commented

@c-smile wow great library! Didn't know about it! Thanks for the hint. However I prefer open source projects and I want to push this further to all kinds of platforms (mobile, ARM...). This should be also the UI base for a new linux system I am working on which focuses on simplicity and security...

Didn't know about it!

Hmmm... It is 10 years in production already. Since Norton Antivirus 2007 that started using it.

ARM...

Check this: https://sciter.com/sciter-on-raspberry-pi-3/ - that's on ARM

I prefer open source

Me too if that dev. model would help to motivate people working on it.

Just to let you know: I plan to have static lib target shortly

Static build targets have now been added; please check if these work for you.

r0l1 commented

@c-smile Thanks for the info. However I have some special needs (musl libc) and I have a vision about a new open source UI solution which I would like to test out. If you're interested I can keep you up-to-date and send you the links to the github repo...

@krogueintel great! I'll give it a try soon. Currently I am using a handcrafted golang canvas library, but as soon as I finish the c-wrapper for fastuidraw, I'll update this issue.

r0l1 commented

@c-smile

Hmmm... It is 10 years in production already. Since Norton Antivirus 2007 that started using it.

I am only using Linux & Unix systems and I have a special mindset about antivirus products. So I am not so familiar with those products and how they manage their UIs... But I would recommend that you leave a comment about sciter at the first link I posted. It might be useful for some people!

Me too if that dev. model would help to motivate people working on it.

What about the Linux Kernel, Red Hat, Qt... ?

If you are making c-wrappers for FastUIDraw, I would love to include them in the project; once you feel you are far enough along, I would love to get a pull request

zsx commented

@r0l1 I'd be interested to see your c wrapper, because I'm also working on this. But my current focus is not to write a c wrapper for every feature/function that fastuidraw provides, but just enough for our application. Maybe we can collaborate on this.

@r0l1 @zsx I haven't started working on this, but I'm also interested in your C wrapper.

zsx commented

@krogueintel I noticed that you added the static target, did you solve the ctor-of-static-resource issue? The reason why I'm asking is that I am building it with MSVC as a static library, and I think I ran into this issue. There are lines like this in the generated shader source:
//WARNING: Unable to fetch string resource "fastuidraw_painter_uniforms.glsl.resource_string"

r0l1 commented

My wrapper is in a very early stage and is similar to @zsx idea. I am willing to merge efforts, discuss the initial design and build up a new complete wrapper for fastuidraw. However right now I am very busy with another project :/

@zsx You have to include the static library with special compiler flags. The compiler must not strip unneeded static variables... See my comment above. I didn't try it for fastuidraw, but I am using the same technique for another project.

-Wl,--whole-archive ${FASTUIDRAW_LIB} -Wl,--no-whole-archive

The script fastuidraw-config can be used to get the right flags for linking statically ( I learned of the flags from the comments in this issue and put that to use in the modifications to fastuidraw-config). However, that is for Linux and Msys2, I don't know what flags would be used for MSVC .. I freely admit that I am hesitant about static libs as FastUIDraw pulls in stdc++ and freetype which in turn pull in more...

zsx commented

@r0l1 Thanks for the info. I missed the link option for ld somehow. The equivalent option for MSVC (link) is /WHOLEARCHIVE, and now it works.

@krogueintel Can't we keep stdc++ and freetype separate from fastuidraw? The problem with shared library on Windows is that you need to decorate all of the exposed classes/functions with __declspec(export) or __declspec(import)

Stdc++ is not part of the interface at all, but part of the implementation. Thus, if an application statically links against FastUIDraw, it must somehow get stdc++. Libfreetype IS part of he interface, but that a pure c- interface... A user of FastUIDraw will feed FastUIDraw objects made by Freetype and FastUIDraw will also create some objects itself... So whatever Freetype the application uses and FastUIDraw use must be ABI compatible. That is actually pretty easy because Freetype has a pure C interface ..but the application will still need the symbols for FastUIDraw to use

zsx commented

@ChengCat @r0l1 I pushed my initial c binding at: https://github.com/zsx/fastuidraw/tree/c

Has anyone tried the static build out? I'd like to close the issue.

I confirm that the static build works fine. Thanks!

It looks like I can close this issue since the static build seems to work fine.