Sheplyakov Alexei wrote:

You should definitely read this: http://www.catb.org/~esr/faqs/smart-questions.html

and this: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

WARNING! These pages *DO NOT HAVE ANYTHING TO DO* with GiNaC! They try to give an idea how to ask questions the smart way.

...

I had to do several fresh starts of ginac from .tar.bz2 to find out

...

a workable use of the patch. As usual, patch -p0 < where/the_patch/is

Thanks for the information. I appreciate the helpful comments and information. But I didn't think I was being stupid or rude, and even though the references are likely to be helpful, I am taken aback by the seemingly implicit "prickly-pear" attitude of those articles, and moreover, I think that the advice misses the point that the world of ideas and systems tends to be quite a bit more complicated than what the author presumes. Contrary to what the author seems to believe, I do not think there is a universal, "true", "right", "one-size-fits-all" way to ask questions. Lots and lots of things in computer systems routinely seem to be "broken" and I don't think it is necessarily due to the fault of "Microsoft Windows" or the saving grace of UNIX/Linux systems design. For example, there seems to be no "html" target in GiNaC Makefiles in spite of what the documentation seems to indicate. It's not just GiNaC. It seems to be quite frequent that documentation is often out of sync with actual systems development. So I suppose "stupid" questions would be inevitable. I suppose I could write a book about what's "wrong" with modern computer systems. But that's not my purpose. What I'd like to do is to understand the design philosophy as to why certain legacy practices and legacy designs seem to be needed. So I try to frame my questions in a way that will solve the most problems most effectively rather than to interminably nitpick a million and one questions in protracted, excruciating detail. Design schemes and philosophies matter. (But I also agree that examples and pertinent detail matters.) The "right" level of abstraction matters. But abstraction is an extremely fluid commodity. There is a lot of arbitrariness to it. And it often has the danger of leading to factional ideologies, flame wars, religious wars, and so on. There are lots of unanswered questions I have about GiNaC and its build process. Here are a few of the seemingly more important ones: Why is it necessary to specify the installation root directory at the time of running configure? Why can't that be done _simply_ at the actual time of doing the installation? Why is it necessary to use libtool? Is libtool a "fixed", universal product? Or is it simply something that is tailored specifically to the particular build process, in this case GiNaC's. Why is it necessary to compile each library module twice? (I suppose the idea is that two different versions are needed for the two different potential forms of the library: "static" and "shared". Is this true?) If a .dll version is not possible, can all the excess machinations be eliminated by declaring "--disable-shared" on the configure command line? Shouldn't a comment to this effect be put in the installation documentation so that mingw-users don't needlessly go through the excess machinations in the hopes of getting a .dll? There are probably other important questions that ought to be asked here, but the above are the more salient ones that come to mind. Sheplyakov Alexei wrote:

./configure && make && make check && make install

works just fine.

If you happen to know a standard, "legacy"(?) configuration of your system that GiNaC build is happy with, I would expect your results. But when systems have a horrendous variety of degrees of freedom for creative, alternative designs, it is amazing the build process works at all. In any case, I would think it important to design the general build process to be both robust and flexible. Maybe this is not the right place to ask this question, but it does seem to matter here the most (grep is such a common tool that I doubt if there is a specific, preferred forum for this): I have not been able to get (cygwin or any other) grep to do a routine, "recursive" sweep through _all_ subdirectories. I have only been able to get sweeps at only fixed depths by using, for example, "./*/*/*" for the filename specification. Can anyone explain how to get a complete recursive sweep through all subdirectories with grep? The documentation seems to be silent on precisely what's needed here. Examples would help.