Re: saving AC development strength

[Bruce Korb]

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