%% [EMAIL PROTECTED] (Toomas Rosin) writes: tr> Well, make's code is not easy to debug (deep recursion), and I tr> have not done this before. I certainly do not see all the issues tr> even now, after spending a long and busy day gdb'ing it. I simply tr> tried to find the simplest working solution.
Sorry; I certainly didn't mean to dis your work; you got much farther than most :). If you like you might save some debugging time next time by dropping a line to [EMAIL PROTECTED] to see if anyone else has hit it. Of course, the debugging can be fun and you definitely learn a lot more that way :). pds> However, the basic idea behind your proposed fix might be cleaner pds> than my solution; I'll have to think about it. tr> Well, my version is perhaps better in that it makes the `func_*' tr> functions uniform. That doesn't matter much to me: eval is a special function and if, internally, it is implemented in a way different from the other functions that's OK w/ me. I find it cleaner (perhaps) because it better preserves the concept of the variable_buffer and how it is used everywhere else in the code (not just the functions). The fact that it has never been necessary to write a push/pop function before shows that the paradigm has worked. Now, as I said, I don't really like this paradigm: the knowledge of when you need to use an allocated output buffer versus a normal output buffer requires some pretty deep understanding of many areas of the code, which I don't think should be necessary. I would like to replace variable_buffer with something different, a very lightweight "scratchpad" implementation I've been working on as a _very_ low-priority item. But up until that change I would prefer to follow the existing paradigm where possible rather than inventing a new one--that seems to me to be even more gross :). pds> Pushing/popping the buffer is very safe, but kind of gross. tr> I would say "simple and robust" instead of "gross" :-) Had I got tr> the idea, I would not have hesitated to use it. In the process of tr> creating my own fix, I felt unsafe all the time. I mean "gross" in this specific context, given that so far the code has not needed it. Or, put another way, to me it's almost always more gross to invent a new, additional API than to simply continue to use what is already used everywhere else :). -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
