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

Compile fails for Nuklear #24

Open
icexin opened this issue Aug 7, 2021 · 6 comments
Open

Compile fails for Nuklear #24

icexin opened this issue Aug 7, 2021 · 6 comments
Labels
bug Something isn't working

Comments

@icexin
Copy link

icexin commented Aug 7, 2021

$ cat nuklear.c
#define NK_IMPLEMENTATION
#define NK_INCLUDE_FIXED_TYPES
#define NK_INCLUDE_STANDARD_IO
#define NK_INCLUDE_DEFAULT_ALLOCATOR
#define NK_INCLUDE_FONT_BAKING
#define NK_INCLUDE_DEFAULT_FONT
#define NK_INCLUDE_VERTEX_BUFFER_OUTPUT

#include "nuklear.h"

nuklear.h is from https://github.com/Immediate-Mode-UI/Nuklear/blob/master/nuklear.h

Output of cxgo file nuklear.c

Error: parsing failed: nuklear.h:428:1: front-end: undefined: size_t
nuklear.h:429:1: front-end: undefined: size_t
nuklear.h:430:1: front-end: undefined: size_t
nuklear.h:431:1: front-end: undefined: size_t
nuklear.h:432:1: front-end: undefined: size_t
@TotallyGamerJet
Copy link
Contributor

I was actually just testing this. I got a similar error but at a different location in nuklear.h.

nuklear_context.c: parsing failed: .../Nuklear/src/nuklear.h:207:1: front-end: undefined: size_t
.../Nuklear/src/nuklear.h:208:1: front-end: undefined: size_t
.../Nuklear/src/nuklear.h:209:1: front-end: undefined: size_t
.../Nuklear/src/nuklear.h:210:1: front-end: undefined: size_t
.../Nuklear/src/nuklear.h:211:1: front-end: undefined: size_t

Strangely ,nuklear.h doesn't include stddef.h and it doesn't use size_t anywhere so I'm a little confused why it's erroring

@dennwc
Copy link
Contributor

dennwc commented Aug 7, 2021

I think you could workaround it temporarily by using define section in cxgo config, see example.

@TotallyGamerJet
Copy link
Contributor

TotallyGamerJet commented Aug 7, 2021

Oh correction. nuklear.h does in fact include stdlib.h which include stddef.h

@icexin
Copy link
Author

icexin commented Aug 7, 2021

$ cat cxgo.yml
define:
  - name: size_t
    value: int

files:
  - name: nuklear.c

$ cxgo
2021/08/07 13:07:25 writing to /home/fanbingxin.linux/test/nk
2021/08/07 13:07:25 nuklear.c
Error: nuklear.c: parsing failed: nuklear.h:428:1: front-end: undefined: size_t
nuklear.h:429:1: front-end: undefined: size_t
nuklear.h:430:1: front-end: undefined: size_t
nuklear.h:431:1: front-end: undefined: size_t
nuklear.h:432:1: front-end: undefined: size_t

Still the same error.

@dennwc dennwc added the bug Something isn't working label Aug 18, 2021
@dennwc
Copy link
Contributor

dennwc commented Aug 18, 2021

Shortest reproducer:

int a = sizeof(int);

And the error:

sizeof_only.c:2:9: front-end: undefined: size_t

Which definitely comes from cc, so I opened an issue.

For now the workaround is to remove define from the config and add typedef int size_t; before #include "nuklear.h".

Nuklear still doesn't compile, but with a different error, which deserves a separate issue.

@dennwc dennwc changed the title compile failed for nuklear Using sizeof without additional includes fails Aug 18, 2021
@dennwc dennwc changed the title Using sizeof without additional includes fails Compile fails for Nuklear Aug 18, 2021
@dennwc
Copy link
Contributor

dennwc commented Aug 18, 2021

Additional #define is required to make Nuklear compile at least partially:

#define NK_INCLUDE_STANDARD_BOOL

Another failure on NK_ALIGNOF is related to #31, but can be worked around by defining _MSC_VER.

Next, it makes sense to map Nuklear's stbtt_(u)intN types to cxgo fixed int types:

define:
  - name: stbtt_uint8
    value: _cxgo_uint8
  - name: stbtt_int8
    value: _cxgo_sint8
  - name: stbtt_uint16
    value: _cxgo_uint16
  - name: stbtt_int16
    value: _cxgo_sint16
  - name: stbtt_uint32
    value: _cxgo_uint32
  - name: stbtt_int32
    value: _cxgo_sint32

There was a bug with missing fmod function, now fixed by 18fb1b5.

Next error is related to NK_OFFSETOF used in NK_CONTAINER_OF and also caused by #31. Temporary workaround is to replace definitions in nuklear.h with:

#define NK_OFFSETOF(st,m) offsetof(st,m)
#define NK_CONTAINER_OF(ptr,type,member)\
    (type*)((void*)((char*)(1 ? (ptr): &((type*)1)->member) - NK_OFFSETOF(type, member)))

This finally allows cxgo to convert the code, but it then fails on gofmt due to a collision between type names and function names which is #32. It can be fixed by renaming these functions:

files:
  - name: nuklear.c
    replace:
      - old: 'nk_vec2('
        new: 'nk_vec2f('
      - old: 'nk_vec2i('
        new: 'nk_vec2if('
      - old: 'nk_rect('
        new: 'nk_rectf('
      - old: 'nk_recti('
        new: 'nk_rectif('
      - old: 'nk_font_baker('
        new: 'nk_font_bakerf('
      - old: 'nk_font_config('
        new: 'nk_font_configf('

At the end there are a few more issues that you'd have to fix on a case-by-case basis (either manually or with replace).

I will come back to this later to file issues on Github and eventually fix them.

So the config I have at the moment is:

package: gonuke
int_size: 8
ptr_size: 8
define:
  - name: _MSC_VER
  - name: stbtt_uint8
    value: _cxgo_uint8
  - name: stbtt_int8
    value: _cxgo_sint8
  - name: stbtt_uint16
    value: _cxgo_uint16
  - name: stbtt_int16
    value: _cxgo_sint16
  - name: stbtt_uint32
    value: _cxgo_uint32
  - name: stbtt_int32
    value: _cxgo_sint32
files:
  - name: nuklear.c
    replace:
      - old: 'nk_vec2('
        new: 'nk_vec2f('
      - old: 'nk_vec2i('
        new: 'nk_vec2if('
      - old: 'nk_rect('
        new: 'nk_rectf('
      - old: 'nk_recti('
        new: 'nk_rectif('
      - old: 'nk_font_baker('
        new: 'nk_font_bakerf('
      - old: 'nk_font_config('
        new: 'nk_font_configf('

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants