[waffle] Windows library is almost up

Chad Versace chad.versace at intel.com
Thu May 22 17:53:50 PDT 2014


On Thu, May 22, 2014 at 10:08:04PM +0100, Emil Velikov wrote:
> Hi guys,
> 
> A bit of update + a couple of questions:

> Should I keep these emails out of the waffle ML?

Please continue to send these emails to the list.

Technical conversation like this should occur in public. It allows
others to provide feedback. It allows others to learn the motivation
behind decisions. It permits mail archives to provide a semi-permanent
public record of the planning process.

>  1. Modified cmake build. Now we have a windows libraries (cross-compiled with
> mingw-w64).

Great!

>  - Why do we use absolute paths for the install targets ? I believe that
> (cmake guys confirmed) one should normally use relative ones.

Per our IRC discussion, Waffle's cmake should install to
CMAKE_INSTALL_LIBDIR, not CMAKE_INSTALL_FULL_LIBDIR.

>  - To the best of my knowledge one should not define symbols such as
> WAFFLE_API/restrict in public headers. Is that intentional or am I missing
> something ?

WAFFLE_API
----------
When I chose to declare WAFFLE_API in waffle's public header, I decided
to follow the precedent set by the public GL header <GL/gl.h>, which
defines GL_API and uses it to annotate all function prototypes.

I chose the wrong project as precedent.  I should have followed systemd
or Wayland's convention for __attribute__("default")).

You're right. Waffle's public header should not define WAFFLE_API, and
__attribute__(("default")) should annotate function definitions rather
than prototypes. I 

Bug filed at https://github.com/waffle-gl/waffle/issues/12


restrict
--------
Right, a public header shouldn't define 'restrict'.

The only public function declared with restrict is

    bool
    waffle_is_extension_in_string(
        const char *restrict extension_string,
        const char *restrict extension_name);

A quick glance at the function body reveals that pointer aliasing should
not alter the function's behavior, so 'restrict' here provides no
benefit. And the presence of 'restrict' does not alter ABI. So, to solve
the problem, you should just remove 'restrict' completely from the
function's prototype and definition.

Bug filed at https://github.com/waffle-gl/waffle/issues/11

>  2. Fully stubbed the windows library, added the dlopen/dlsym[2].
>  - Windows supports ANSI and Unicode versions of most functions. Considering
> the use-case I'm going with ANSI. Objections/suggestions ?

I have no opinion on #2. I defer to Brian and Jose.




More information about the waffle mailing list