>>>>> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> have to recompile at each reconfigure? I don't unless config.h has >> actually been changed. Abdelrazak> But that's my point, one should not have to recompile Abdelrazak> everything because of a single setting change that impact Abdelrazak> the compilation of a single file. So it does not recompile at each configure? Only when config.h actually changed? Abdelrazak> This is fixed at boost level. Code in BOOST_ASSERT will be Abdelrazak> executed or not depending on the _BOOST_ policy. You Abdelrazak> should not have to check for ENABLE_ASSERTION. >> Hmm, and how do you tell boost whether we want the assertions or >> not. Abdelrazak> That's exactly what I am saying, it's boost job. There's Abdelrazak> _no_ need to check for ENABLE_ASSERTION in LyX code. I am Abdelrazak> not saying that this macro is not useful but that changing Abdelrazak> it should not imply a complete rebuilding. If you want to Abdelrazak> enable assertions globally, "make clean" first. Ah, you mean explicit test on ENABLE_ASSERTIONS? There are two uses, and they are indeed not needed. Abdelrazak> Yes? >> I am not going to do your homework. Abdelrazak> I almost put a smiley here... Yes, but you've got to be strong! >> No. You have not only to be mean, but also to be right. Abdelrazak> I think I am, we just don't have the same definition of Abdelrazak> truth. I understand what you want to do, but there are some things for which we need config.h. For example: CXX_GLOBAL_CSTD, DEVEL_VERSION, concept checking and stdlib-debug stuff. Note also that config.h defines some types that are not existing in some systems. I think that having a place where we can propagate stuff to all files is very important. It would be better if autoconf allowed us to have several separate config.h files with different uses. This is unfortunately not possible, unless we use several configure files (do you want that? It is going to be even slower). However, if you are annoyed because you need to recompile when configure.ac changes, this does not happen very frequently in general. JMarc
