I can avoid modifying drm.h by doing this to drm_fourcc.h:

#ifdef _WIN32
#include <stdint.h>
typedef uint64_t __u64;
#else
#include "drm.h"
#endif

And this to amdgpu_drm.h:

#ifdef _WIN32
#include <stdint.h>
typedef int32_t  __s32;
typedef uint32_t __u32;
typedef uint64_t __u64;
#else
#include "drm.h"
#endif

But now I'm touching two files under drm-uapi instead of one, and weirdly.

If we're trying to cut ties with the drm-uapi folder entirely, the stuff ac_surface.c need includes the AMD_FMT_MOD stuff in drm_fourcc.h, and AMDGPU_TILING_* under amdgpu_drm.h. Is there a better spot for these definitions?

Thanks,
James

On Wed, Dec 2, 2020 at 10:06 AM Michel Dänzer <michel@daenzer.net> wrote:
On 2020-12-02 1:46 p.m., Daniel Vetter wrote:
> On Wed, Dec 2, 2020 at 12:43 PM Michel Dänzer <michel@daenzer.net> wrote:
>>
>> On 2020-12-01 11:01 a.m., James Park wrote:
>>> This will allow Mesa to port code to Windows more easily.
>>
>> As discussed in
>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712779
>> , including drm.h makes no sense when building for Windows.
>
> Yeah I think it'd be cleanest if we can avoid this. If not I think the
> right fix would be to split out the actually needed parts from drm.h
> into a new header (still included by drm.h for backwards compat
> reasons) which mesa can use. Since it looks like the problematic parts
> are the legacy gunk, and not the new ioctl structures. Pulling out
> drm_render.h for all the render stuff and mabe drm_vblank.h for the
> vblank stuff (which would fit better in drm_mode.h but mistakes were
> made, oops).

If anything currently in drm.h is needed while building for Windows, it
points to a broken abstraction somewhere in userspace. (Specifically,
the Mesa Gallium/Vulkan winsys is supposed to abstract away platform
details like these)


--
Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer