Re: RE: Differences between mingw-make and msys' make

[Soren A]

Earnie Boyd <address@hidden> wrote around 25 Sep 2002
news:address@hidden: 

> As, I said above, I was aiming for clarification.  I was trying to
> clarify in order to be productive.  Sorry you were offended.

OK. I get a bit touchy when I've been working for many hours
(particularly on tasks involving software systems which I find basically
loathsome and inimical to my Happy Programming Life...) even though I
know better. 

> Soren A wrote:
>> 
>> Earnie Boyd <address@hidden> wrote around 24 Sep 2002
>> news:address@hidden:
>> 
>> > So, the real problem for this is Soren, or something else?
>> 
>> In a bad mood tonight, Earnie?

> No, I was asking for clarification of 
>> > As per above, this was a major issue (because I decided to make it
>> > one ;-).
> I don't know how to comprehend the statement to it's intent.

Sorry I wasn't more clear. That was one of "those touches of humor". Of
the self-deprecating variety. 

Major issue -ness can be in the eye of the beholder, is all I meant. I
could see somebody reviewing my changes saying that I neededn't have
worried about the part of the build in question. 

Let's back up and review what's going here. 'make' requires directory
globbing functionality. On some platforms it's going to get it
automatically, if I understand correctly, because the system already has
the "GNU Glob" headers in libc. MinGW and Cygwin of course do not even
have libc, let alone the glob stuff. So we are going to need to compile
libglob in the glob/ subdir. 

Linking in a C library archive to an application can be done by
including the entire archive (which amounts to the same thing as simply
listing each constituent object file that is in the archive, on the ld
command line after the app's own object file(s)). That's probably not
inappropriate here because it's likely that 'make' needs everything
that's in 'libglob.a'. I conceed that point. It's just that I was
bothered by the stylistic infraction this represents: it's not what i
expect a 'Makefile' to do. I expect, instead, the Makefile to provide
proper -L and -l parameters to the linker so that it can select from
within the archive just what it needs to resolve the external symbols in
the application's object code. 

So my changes pertaining to this cause that to happen, but a bit
conservatively and only when GNU 'make' is being used to build (GNU
'make'). Since this isn't a critical issue, all that results if the user
isn't running GNU make to do the build is that the whole archive gets
included as just described above. Which probably happens anyway. The
build doesn't fail if the user doesn't have GNU make. 

The reason GNU make is tested for is two-fold. First, if the user has
GNU make the likelihood is quite high that they are also using gcc (and
gnu ld). Thus an oddball compiler that doesn't grok '-L' and '-l' (I
guess there are some?) is not likely to get fed them. Secondly, a system
that has libc and has GNU glob already won't have anything present in
the macros GLOBLIB and GLOBINC that wind up in the autogenerated
Makefile. Right? Those will be null macros. If I start adding '-L' and
'-l' to null strings I will wind up feeding garbage to the linker in
those cases -- broken build. 

The solution to that is to use GNU make -specific features. Another way
could be found (TMTOWTDI). No doubt someone would want to see a
configure-based way to do it. I basically do not like autotools and it's
my time and my work, so I used instead a program I *do* like: 'make'. I
used the functions built-in to GNU make $(addprefix) and others to
create the right linker arguments and the impact of that approach is
that if the macros are empty to begin with, nothing (no garbage) gets
added to the params to ld when 'make(.exe)' is being created. That is,
the GNU 'make' functions like $(addprefix foo,bleah) do return null
strings if they are fed null strings. I happen to think that's really
neat.

I believe that my solution is generalizable to other situations where a 
library is being built in-place and because of that I felt it was worth the 
time to work out how to do it. 'libtool' is commonly employed nowadays by 
some people I think, to supply answers for issues like this. I don't want 
to introduce libtool into my patches or my brain at the present time. I 
think it's a 200-kg solution for what is often a mere 5-g problem.

> I didn't mean to offend you, and yes I find your posts most
> informative with some touches of humor.
> <snip> One thing you do well is verbosity. ;)

General broadcast apology for that. When I am on the other end of
needless verbosity, believe me I do understand that its stressful. It's
not my intent to stress anyone. I nonetheless still sometimes absolutely
need to do 'thinking out-loud' in my written posts, otherwise I get into
a deadlock I cannot break. That's probably a consequence of the way my
mind works, the way I am wired. I am not a particularly linear thinker,
I am left-handed and (as is statistically correlated to that) am ADD/HD
(Adult Attention Deficit "Disorder"). My mind works sideways at least as
much as it does forewards and backwards. A lot of other hackers are
ADD/HD -- my layman's guess based on general observations over the years
at that as many as 50% of the particpants of this List may be ADD/HD
(even if they don't yet know what that is, and if they don't I encourage
them to find out, although I am not advocating any particular
pharmacological treatment for it or anything. It can impact a lot on
one's quality of life if Adult ADD/HD goes undiagnosed).

Hopefully I have explained what was my "issue (3)" well enough that its 
clear now. What would probably be more useful to more people is if a test 
were created at 'configure' time to see if we are MinGW AND didn't put 
anything into GLOBLIB and GLOBINC -- because if that happens something is 
malfunctioning and the build will break at the linking step if not before.

Lastly I want to touch on issue (2) from my o.p. That one concerned the 
compilation of getloadavg.c ... basically the kludge wherein it gets cp'd 
from the srcdir to the builddir under the name 'loadavg.c':

  loadavg.c: $(srcdir)/getloadavg.c
        cp $(srcdir)/getloadavg.c $@

I think some might have misunderstood. The problem with my first fix was 
not that it relied on VPATH. If VPATH isn't working then one isn't goign to 
be building in a remote dir anyway. The problem I was referring to ("GNU 
doesn't recommend") concerned $<. $< isn't reliable when used outside of 
rules of the suffix variety(??) on all make's. GNU make handles such 
application of this technique fine, but not all other make's do. The way I 
have it written above is now GNU-correct based on the manual at the GNU 
site.

If the build dir and the src dir are one and the same, John Cronin's patch 
doesn't fail. I'd like to make the point now to all reading to try to keep 
in mind that if you are hacking on GNU-style configure's then you need to 
*test* your hack by building in a external dir, period. Whether you *like* 
it or not. It's a matter of individual taste (some like one way, some the 
other) what you do in the privacy of your own project, but if you are 
hacking on a GNU autoconfigure then you need to conform (resistance is 
futile. you will be assimilated ;-). If you don't test your hacks by doing 
a build run the GNU-proper way you run the definite risk of submitting 
buggy build-patches that are non-GNU-proper. And pissing-off those of us 
who build outside the src dir ;-).

  Thanks,
     Soren A