On 2019-12-23 18:37, Ludovic Courtès wrote:
> Hi,
> 
> Giacomo Leidi <goodoldpaul@autistici.org> skribis:
> 
>> * gnu/packages/game-development.scm (libtcod): New variable.
> 
> Could you (1) add a ‘snippet’ that removes zlib and utf8proc from
> src/vendor (assuming it doesn’t break the build system…), and (2) add
> utf8proc as an input?
> 
> That way we’d make sure we don’t end up using bundled copies of these
> packages
> 
> Apart from that it LGTM, thanks!
> 
> Ludo’.

Hi Ludo',
Sorry for the delay. I checked and it seems that a lot of vendor library 
paths are hardcoded in the C headers.

I made a new patch with a snippet that deletes zlib sources, but I'm 
unsure about how to approach the hardcoded paths.

grepping for 'vendor' inside the source returns


src/libtcod/sys_sdl_img_png.cpp
41:#include "../vendor/lodepng.h"

src/libtcod/console/printing.cpp
54:#include "../../vendor/utf8proc/utf8proc.h"

src/libtcod/sdl2/gl2_ext_.h
36:#include "../../vendor/glad.h"

src/libtcod/color/canvas.cpp
39:#include "../../vendor/lodepng.h"

src/libtcod/tileset/truetype.cpp
43:#include "../../vendor/stb_truetype.h"

src/libtcod/tileset/tilesheet.cpp
34:#include "../../vendor/lodepng.h"


As far as I understood (I'm no C wizard) lodepng, glad and stb are 
libraries which are designed to be dropped inside a source tree and 
statically built in binaries. Right now I think those are secondary 
problems and the main deal is how to effectively replace the included 
utf8proc.

I'm not sure if replacing every "#include ../../vendor/something.h" with 
"#include <something.h>" ( by including a .patch file or with 
substitute* ? Food for thought :D) and then placing something.h inside a 
path known by the C linker is enough but it's the  I'm not really sure 
where to go from here.

Any advice is very welcome, thanks.

Giacomo