Peter Eisentraut wrote: > I admit to have looked at it a few times, but never really figured out > what it would do for me. (Plus, having to enter your name and having > everything logged isn't exactly what draws testers.)
I was imitating the ac-archive stuff. I should make it clearer that leaving it blank only eliminates the "dnl @author ..." stuff. > A few minutes ago I > just tried it out with a macro that I already had written, but I must > conclude that the interface is extremely limited and hard to understand, > and the macro I got as output is not exactly pretty. Yes, it is limited. It is also programmable, so if it can be made straight forward to use, then effort can also go into making it "less limited". > To start, the "half-line description" input field is too short, and it > automatically prepends the word "whether", which is not what I want. It also automatically prepends "define this if". I am certainly open to suggestions (including two separate inputs), but the goal was to not have to say essentially the same thing in slightly different ways depending on whether it was for the AC_MSG_CHECKING output or the AC_DEFINE output. Obviously, the grammar is easier if you are not trying to overload the usage. > The AC_DEFINE description string also reads strangely. Now, you know why :-) > The macro uses dnl comments when # should be used. Point out what you want to see as "#" comments, thanks! > Changequote is going to get you into trouble with Akim. That presents an interesting problem. There is no guarantee that an arbitrary input program will have balanced square brackets. Given that, there are two choices: 1. change the quotes to something that is pretty certain to stay out of the way {e.g., changequote(<<<,>>>) } 2. Scan the text for an imbalance and change quotes only if necessary. That takes real work. > I don't know what this $ag_poplang variable is > supposed to do, but I've never felt the need for it in hand-written > macros. The documentation for the PUSH/POP language macros (viz., the comments in the source) say that you cannot just willy-nilly wrap the push inside of a test to see if the desired language is already current. The issue is that I believe you do not have control over what happens when you get to the pop-language, but I am not certain. What I believe, though, is that it takes a lot of work to change the current language. Therefore, if it can be avoided, it should be. If I am wrong about that, then that variable and the conditional wrappers around the push/pop can go away. > If I just want to compile something I can just write AC_TRY_COMPILE (or > AC_COMPILE_IFELSE, or whatever it's called these days) myself. If I'm > looking for something more complicated I need to do my own programming > anyway or resort to an archive. You are familiar with how this all works. But also, it is a bit more than AC_TRY_COMPILE and AC_COMPILE_IFELSE. You also must set up a way for communicating results to the build mechanism, either with substitution texts or #define names. You also need a cache variable. I found wending my way through the docs rather intimidating (~three years ago, admittedly). My intent here was to lead someone who knew what they wanted to have happen through the process of assembling the pieces. I think an interactive form is easier than wandering through archives. I was also sure that the forms could use feedback and improvement.... > Just my impression. Thank you! I'll go over the pages with an eye towards, "what would be confusing" to see how I might polish it... Regards, Bruce P.S. layout of the macro: it isn't easy, but if you have a suggestion (just show me the result & the way you would expect it), I'll do what I can... -- Bruce Korb <full.name at veritas com> URL: http://autogen.sf.net/conftest.html