Danny Backx wrote: > On Fri, 2006-12-29 at 15:35 +0000, Pedro Alves wrote: > >>Danny Backx wrote: >> >> >>>>>@@ -1,4 +1,10 @@ >>>>> # >>>>>+# This is a Makefile.in for very limited use : only create and install >>>>>+# the profiling runtime for cegcc (arm-wince-cegcc and >>>>>arm-wince-mingw32ce). >>>>>+# >>>>>+# This should NOT be fed back to the MingW project as is, it doesn't fit >>>>>+# nicely into their sources. >>>>>+# >>> >>> >>>>Yikes! Why are these changes needed? Ah, you used --target, instead of >>>>--host. >>> >>> >>>The answer is above : I adapted the src/mingw/profile build so it could >>>work as a standalone directory. The reason is that we need this stuff >>>for cegcc as well, and we can't install the src/mingw tree there. >>> >>>Don't you remember that we chatted about that, and I said I'd implement >>>this as a standalone directory ? I asked where it should be (src/mingw >>>is not the right place for it) but we never made a decision on that. >>> >> >> >>Yes, I do remember. But the way you've done it is the wrong way. > > > Grmbl. I wish you told me this before. >
Deeply sorry. :( I didn't try, but, are you sure, just passing --host doesn't build with cegcc as it is? >>>>But, I think it would be better to leave the host part as it was (get rid of >>>>"GCOV_CROSS_PREFIX"), and just replace the getenv calls in mingw32ce version >>>>with WinCE Registry keys. In cegcc.dll the environ already comes from the >>>>registry. That way, the only thing special about WinCE profiling in >>>>comparison with other gcc targets, would be that you set a Registry key, >>>>instead of doing a shell export. Much more flexible, IMHO. >>>>I would go as far as implementing the a function that reads from >>>>the registry with the same interface as getenv, returning a pointer >>>>into a local static buffer, to keep our patch isolated, and call that >>>>instead of getenv. >>>> >> >>Easy doesn't mean the best :) What my version allows is to change the >>profile dir without rebuilding the app, just change the key. That is >>also the idea behind the original getenv/environ version. > > > You're missing one point : the current situation is that executables > have a path hardwired into them. I've just added an option for it to be > a valid path. The target-specific (GCOV_PREFIX and GCOV_PREFIX_STRIP) > hacks remain valid in cegcc, and in mingw too after I implement your > getenv replacement idea. > I do understand that. Since it has always worked like that, I do wonder if in the end that feature is really needed. I mean, everyone must just set GCOV_PREFIX and be done with it, else there would already be an option for this. I still think that if you want a host option, it should be a command line switch, not an environment variable. But anyway, if you want to go with it, fine. Cheers, Pedro Alves ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
