[GiNaC-list] Results of GiNaC (& CLN) builds

[Richard Haney]

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.