On Sun, Sep 23, 2012 at 9:28 PM, Zdenek Styblik <zdenek.styb...@gmail.com> wrote: > Hello all, > > pardon a bit ambiguous and perhaps a bit poetic subject. I've noticed > following # ./configure --enable-intf-open --enable-intf-bmc ; doesn't > result in what I'd expected. That is enabling interface BMC and > OpenIPMI. I've filled bug for the former, because there is a bug in > configure.in which disables BMC interface on SPARC platform. Yes, I do > dare call it a bug, because that's what it is. The latter, OpenIPMI, > should work automagically. That is, if foo.h is not found, then try > bar.h, then try something else, and if everything else fails, use > "internal" header file. That's what configure output tells you anyway. > None the less, you'll end up with ``open: no'' and OpenIPMI interface > doesn't get compiled in. Actually, I'm going to fill artifact(why > SF.net, why? I mean, omg!) as well. > > Now, when I say, execute, # ./configure --enable-intf-bmc > --enable-intf-open ; shouldn't I get what I want? And if something is > missing, say header files, shouldn't I be told about it with # > ./configure; crashing big time, eg. like when no C compiler could be > found? I believe this should be the very same case. > I haven't investigated this deeply (yet). There are per-os-type > defaults which are great. And they should be over-ridable. However, it > seems they're not. > > What do you think; bug or feature? > > Regards, > Z.
Ok, I've spent some considerable time debugging this issue. It turns out the poor choice of variable names is to blame. To be more specific, you shouldn't use and re-use variables the (M4) macros are using. Attached is a patch that fixes issues with enabling/disabling ipmitool's support for interfaces. If there are no objections and comments, I will commit it by the end of (next) week. Please, do the diff review; test it; try to break it as well! However, issue with # ./configure; not failing big time when some library/header is not found remains. I haven't poked into it and is perhaps for another run. What I mean is shown below: ~~~ # ./configure --disable-intf-lanplus --disable-intf-open --enable-intf-bmc --enable-intf-lipmi [...] checking for termios.h... yes checking sys/lipmi/lipmi_intf.h usability... no checking sys/lipmi/lipmi_intf.h presence... no checking for sys/lipmi/lipmi_intf.h... no ** Unable to build Solaris 9 x86 IPMI interface support! checking for library containing tgetent... -lncurses [...] config.status: executing depfiles commands config.status: executing libtool commands ipmitool 1.8.12 Interfaces lan : yes lanplus : no open : no free : no imb : yes bmc : yes lipmi : no Extra tools ipmievd : yes ipmishell : yes ~~~ If you can't build feature user has requested, then fail big time. Some checks, however, are sacrifice between speed/simplicity and "logic". I mean, eg. OpenIPMI is being checked regardless whether OpenIPMI interface is enabled or not. And the very same goes for LAN interfaces. I presume it is easier and faster do it this way. And it doesn't make sense to fail in these cases since result is used later on. However, # ./configure ; should fail later on when, eg. user requested LAN+ interface, yet he lacks OpenSSL libraries. Have a nice day, Z.
configure.in.diff
Description: Binary data
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
