autotools based build for portability and cross-compilation

[hanetzer]

As above. I'm currently working on setting up an autotools build-system for mkxp, and making good headway into it. Would greatly simplify some issues involved in compilation, using a single configure script with options to produce working binaries for any system :)

[hanetzer]

Good news, I got a working autotools build for linux, now for the cross-build stuffs :) may be a bit before I actually push and make a pr, before I can learn what needs to be on the repo and what doesnt.

[Ancurio]

Have you tried with cmake before?

[hanetzer]

Yep, but cross compilation is a bit of a pita with it. I already have it almost finalized. All I have left now is to do xxd processing and a little bit of platform-specific stuff (mainly the -mwindows on windows non-debug builds)

[hanetzer]

AND DONE! I can build a linux and windows binary from the same configure script :+1:

[carstene1ns]

Using a small toolchain file for cmake and maybe adding some glue code inside the CMakeLists.txt would be a better idea IMHO.

[hanetzer]

I'm just not a huge fan of cmake, kinda oldschool in a lotta ways. so far x86_64-unknown-linux-gnu and i686-w64-mingw32 targets work (even with the boost lack of pkg-config), don't have the libs prepaired to test against darwin targets.

[Ancurio]

@ntzrmtthihu777 First off, I really appreciate your intent on contributing. As an end user, I definitely prefer automake based projects to cmake too.

However, I'm also not a huge fan of maintaining three separate build chains (I already have trouble keeping cmake working lol), for something I'd deem a questionable gain. I'd really like to explore the possibility of bending the existing CMakeLists.txt to create clean mingw builds first (or possibly qmake, either is fine).

[hanetzer]

@Ancurio No problem, but consider this. As far as I can figure, you use qmake for the ability to use the qtcreator IDE (which I recently discovered to be damned nice, alot like IDEA for C++); but, as you said, as an end-user autotools is so damned easy (especially since I found a m4 macro to locate boost for you in spite of the lack of pkg-config).

[Ancurio]

especially since I found a m4 macro to locate boost for you in spite of the lack of pkg-config

Interesting. How does it do that? Does it scan the entire filesystem or use locate to check every possible directory for the headers?

[hanetzer]

not sure, source code is at https://github.com/tsuna/boost.m4

[carstene1ns]

It has a predefined list and also supports setting it with command line argument (--with-boost=/path/to/boost) and uses the environment variable $BOOST_ROOT if defined. FindBoost.cmake does nearly the same btw. :grinning:

[hanetzer]

Eh. I just don't like cmake. The ./configure && make invocation is second nature to me :)

[hanetzer]

@Ancurio hey, I don't suppose there is some form of real-time communication we could engage in? I've some questions regarding the build process using mruby and a few other things I'd like to discuss.

[Ancurio]

@ntzrmtthihu777 I sometimes idle in #easyrpg at freenode, will be there if you need help (if not I'm asleep).

[moocow1452]

An automake might be useful for Android stuffs, mostly because to get around the SDL_sound fun and games, I think you need to make separate toolchains rather than just use the NDK build script to make your standard three. (x86, ARM, ARMv7)

[hanetzer]

Question regarding the embedded shaders and font; I notice you use a char pointer in Shader::init with xxd, I've been working on using objcopy to do the embedding, and was running into trouble with that. I can get mkxp to compile but it either segfaults or throws MKXPException on running, so I was wondering if the way you're loading shaders is built around xxd embedding or if the SDL2 guts requires a particular method

[Ancurio]

so I was wondering if the way you're loading shaders is built around xxd embedding or if the SDL2 guts requires a particular method

You'll have to be more specific in your question than that. All that xxd's generated output provides is a char array containing all bytes that make up the input file, and an unsigned integer which holds the size of that array. Objcopy gives you two symbols _start and _end, so you have the same available in the form of &_start and (&_end - &_start); if you're unsure what's going wrong just set a breakpoint inside Shader::init and verify that the arguments point to valid data / lengths.

There is zero SDL2 involved with the embedding (apart from reading the data).

[hanetzer]

Gotcha. I was using some info from a linuxjournal article on the usage of objcopy in this regard. Problem is, I'm having issue in regards to making shader.cpp use the objcopy'd symbols properly... I know you normally use the *.xxd files as headers and include them, and they declare the proper stuffs as unsigned char shader_name_here[] and the length, which makes it pretty seamless.

One thing I noticed, is that in my small test program that prints out the data in each symbol given by objcopy is that the length is printed as hexadecimal rather than a standard decimal int (eg 0x124 for blur.frag.o); this however does match up with the length as reported by the xxd'd header... not sure if this makes a difference or not.

You may ask why I'm even bothering... and you'd be right to ask, lol. I just like to fiddle with stuff and this is an interesting angle.

[hanetzer]

ah... it seems my issue is I have a very poor idea of references and pointers XD... apparently _binary_objfile_size does not store the actual data itself... its just points at the right value... must study more.

[Ancurio]

This is how I would use the _size symbol:

extern char _binary_obj_size;
...
size_t size = (size_t) &_binary_obj_size;

[hanetzer]

And finally giving this a nope. int and pointers have different sizes on 64-bit platforms, so... can't easily cast one to the other, due to the 'chopping' effect of going from 64-bit pointer to 32-bit int. Still, was a learning exercise.

@Ancurio See, I had tried a similar thing, everything compiled fine and all that, but I ended up catching some SDLError that it could not open the font file :/

All in all I'm going to just back burner that idea, and work more on the GUI editor toolkit.

[Ancurio]

There is no embedded file in mkxp whose file size exceeds an 32bit unsigned integer.

[hanetzer]

yeah.... wait a minute... I think I know the issue here. Also, I've switched from using objcopy to using ld; it does magick for you and auto-determines the proper binary output type (works with {x86_64,i686}-w64-mingw32-ld as well) :)

[hanetzer]

Yep, I was right-ish XD Finally got that to work, all shaders and the font are now linked in via ld :+1: now to start tweaking things :) You'll notice I didn't mention the icon... I just think that linux's *.desktop file covers that well enough, and there are native windows methods of adding icons to executables in a 'normal' fashion.

[Ancurio]

Well, gratz on your experiment :)

[hanetzer]

also... I think I may (and emphasis on may) continue to use qmake for the building... I figured out how to make it compile for windows, and it works(?), so the next phase is refactoring out boost_program_options.... recompiling it to keep from duplicate sections has different sizes issue for static linking crashed my DE :/

[Ancurio]

At this point, I'd prefer meson over autotools, which is getting phased out by the wider freedesktop.org community.