|
Rockbox mail archiveSubject: Re: Integrating TI CG toolsRe: Integrating TI CG tools
From: Catalin Patulea <cat_at_vv.carleton.ca>
Date: Tue, 27 Nov 2007 11:41:19 -0500 My first instinct to both these issues is to defer them in favour of actually getting sound output working. On the other hand, I can see how a little bit of forethough can save us some headaches in the future. On Nov 27, 2007 10:34 AM, Daniel Stenberg <daniel_at_rockbox.org> wrote: > You can, but I consider it nicer if you check for a particular value or config > that is set in the configure that isn't the exact model number/name. So that > for example future dms320-targets can take advantage of the fix without adding > the target names to the test. Something like DSPBUILD (a boolean), below ROOTDIR, FIRMDIR, et al.? And in firmware/Makefile: ifneq ($(DSPBUILD),) $(BUILDDIR)/dsp-image.h: ... ... endif I still see this as needing per-platform ifdefs because source files will differ across platforms. Anyway. > My biggest thought when I read the patch was: why is this generating a .h > file? Isn't that stuff generating some kind of data or something that is > better (more accurately) placed in a .c file? Some of it has to be in a .h: I read the symbol table from the COFF file and generate #define's that let me access variables in DSP memory by name instead of hardcoding offsets. On the other hand, the actual code indeed is better suited for a .c file. I just got lazy ;-) Making xml2h.py output a .c and a .h will be the easy part.. I'll have to dig around for examples of building a .o from a generated .c :\ Thanks for the feedback, -Cat Received on 2007-11-27 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |