logs archiveBotHelp.net / Freenode / #3dsdev / 2015 / September / 7 / 1
furyhunter
alright
I think maybe, just maybe, I got a working compiler_rt
profi200
Should not clang support most architectures in 1 compiler? It just needs to be configured to replace arm-none-eabi-*.
furyhunter
argh... no hope -_-
definition collisions when linking in rustc...
with compiler-rt and libgcc
fffffffffffffffff
yuriks
doesn't Rust use a forked compiler-rt?
furyhunter
I am pretty sure it's only slightly modified
specifically, target.mk -- arbitrary target triples
soooo sick of trying to get this to wokr
yeah I give up
Lectem
endrift : should be clean so I PRed https://github.com/mgba-emu/mgba/pull/111
profi200
There is now RomFS support. Why not load the font from RomFS?
endrift
profi200: does that work with 3dsx too?
profi200
Yes.
Dazzozo
on 3dsx the code switches to read from the romfs appended to the 3dsx binary
profi200
It supports both. But better don't use dirs inside the RomFS because makerom doesn't calculate the hashtable correctly.
endrift
Lectem: Okay so comments on your toolchain:
You really should have the add_*_target things let the user specify the name of the target, not just the name of the base
yuriks
the joys of 3DS homebrew: adding a 72-byte const array to my program makes it blackscreen
Lectem
endrift> Lectem: Okay so comments on your toolchain << yeah I was thinking about it, but I wasnt sure what would be better
there used to be a few implications I didnt like (using file instead of target and stuff)
but well, i'm open to suggestions
endrift: the main problem with letting the user choose the target name being that he could choose myhomebrew.3dsx, which would create two targets with the same name ( because of add_custom_command and add_custom_target)
I could let the user choose the name of the file though, instead of the target
that might actually work fine
so after a bit of testing, it seems that the circular dependancy and double target issue disappeared, need more testing I guess
endrift : after digging a bit, there isn't any good way to let the use name the target for add_3dsx_target and such
it will always need to be renamed if its the file name, for example add_3dsx_target(mgba.3dsx mgba) would create the files mgba.3dsx and mgba.smdh, but the target real name would be mgba_3dsx
I dont really see why anybody would like to name the 3dsx or cia with a different name than the elf tbh
endrift
Lectem: the point isn't to rename it, the point is for the user to know the name of the target without having to look at the source for the module
Lectem
I see what you mean, but there isnt really a good way to do this unfortunately
giving the user the right to choose the target name but forbidding him to use "name.3dsx" sounds a bit wrong
also since it generates a .smdh, the proper way to do it would be to add 3 arguments, target_name 3dsx_file and smdh_file
I can't find a good solution tbh
profi200
The build systems are all sh*t :p Would be great if one existed which doesn't suck.
Lectem
c++ definitevely need a good build system / dependancy manager
profi200
Lectem: hb menu also accepts boot.3dsx and boot.smdh.
mgzg
ninja
Lectem
unfortunatly, the only one I found was biicode, and it didnt really suit my needs
ninja is a pain to use
its meant to be generated
profi200: I doubt that people would like all their projects creating boot.3dsx and boot.smdh
I was also thinking about trying GYP at some point, but never did it
profi200
boot.* is meant to be placed in a dir with the hb name.
Like boot.3dsx and boot.smdh could be placed inside /3ds/mgba
It's just an alternative way to name the files.
Lectem
well yeah, but it only solves half of my problem I think
cause if you want to build 2 different homebrews from a same cmakelists you'd have to create subdirectorie
s*
and this time the target name could conflict with the elf target (since people usually dont give an extension in cmake)
« prev next »