>>>>> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> You cannot get rid of these "61 unused macros". Abdelrazak> I certainly cannot. But you could. And if not, why is Abdelrazak> that? I am probably missing something here... If we are dissucssing the same These are byproducts of autoconf tests that are done, say, by the gettext m4 macros. We cannot get rid of them. >> Did you read what I wrote? concept checking? stdlib-debug? Do you >> want to link against two different versions of std::string? Abdelrazak> Yes, why not? I am interested in concept checking or Abdelrazak> debugging what I am developing right now. All other debug Abdelrazak> stuff is not needed. If I need to add a compile another Abdelrazak> file with these option, I touch it and "make". What's the Abdelrazak> problem with this approach? I am not sure that std::string with or without stdlib-debug are binary compatible. But I may be wrong. Also, when template instantiations are merged, what happens? >> DEVEL_VERSION is used in src/ (to show some info in the >> minibuffer). I think you need to cleanup all the source code before >> you can even think of removing config.h in src/. What about ccache >> instead? Abdelrazak> I don't know about that. Read about it there: http://ccache.samba.org/ It is supposed to support win32 compiles. >> It is not so easy, because autoconf sucks at this. Abdelrazak> We always end up with this conclusion... The problem is not to acknowledge that autoconf sucks at some things. Autoconf is known to be able to make big programs portable. The question is not how to do easily 95% of what autoconf does, it is the rest. JMarc
