From: Alan W. I. <ir...@be...> - 2006-07-10 08:31:38
|
On 2006-07-10 09:27+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2006-07-09 21:45]: > >> When attempting to follow your m4 autotools logic for devices, I ran >> across what I think may be bugs in our autotools build system. >> >> (1) In acinclude.m4 apparently both PL_ARG_ENABLE_DRIVER and PL_ADD_DRIVER >> call "PL_ARG_ENABLE($1, [enable $1 device driver], $3)". There may be no >> practical consequences to calling PL_ARG_ENABLE twice for each device, but >> Shouldn't this be fixed? > > I think you are right and that the PL_ARG_ENABLE call in PL_ADD_DRIVER must > be dropped. However, I do not have time to do extensive tests now. You > might just do this change in CVS and wait for the users' reactions. If I spot a potential autotools build system bug, I will certainly let you know about it as now, but I don't have time/understanding to do the fix. My lack of understanding is one of my motivations for working on the alternative cmake build system, but also that obviously is absorbing my time right now. Therefore, please put the fix on your autotools maintenance ToDo list. > >> (2) In PL_ADD_DRIVER we have the following test line which I >> believe is incorrect: >> >> if test "$enable_$1" = yes -o "$enable_$1 $enable_drivers" = " yes" ; then >> >> Shouldn't that second $enable_$1 be dropped? Without that change, I don't >> understand how the --enable-drivers option would ever work properly, >> (although I haven't tried that option to see if it actually works or not). > > I disagree. I think that the trick is accomplished by the space > character before the word "yes": > > if test "$enable_$1" = yes -o "$enable_$1 $enable_drivers" = " yes" ; then > ^ > here ------| > > The second part of the logical expression above will only be activated if > both enable_$1 is undefined *_and_* the value of enable_drivers is "yes". Thanks for that explanation of the logic. The one remaining concern for me is this all occurs in the drivers-finish stage. So your above logic will work only if "$enable_$1" undefined is a signal at the drivers-finish stage that the user has not specified a value at the drivers-init stage. I am concerned that $enable_$1 might be always defined regardless of what the user does, but I don't have time to look further into PL_ARG_ENABLE (and struggle with m4 interpretation) to see, for example, whether it always defines a value so that "$enable_$1" always gets defined. Anyhow, I hope you are able to obtain a definitive answer to that question. My own cmake default device logic is 100 per cent completed at the drivers-init stage so it seems more clear (at least to me) what is going on. > BTW, congratulations for your efforts regarding the CMake porting. I hope > you will complete it (and maintain it in the future). Thanks. It is going well. I plan to report to the list about what I have accomplished so far within the next day or so. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |