Re: [Mingw-msys] uname question(s?)

[Paul G. <pga...@at...>]

Hi folks,

	Last few days my email account was down.  Pulled this from archives.

> From: Soren A <soren_andersen@fa...>
> Re: uname question(s?)  
> 2002-09-18 23:09
> 
>  I am glad this discussion is being held. In point of fact this was what I
>  was trying to get at when I posted my article on Sep 10 "Subject:
>  $build_os and other Autotools issues". I had in mind these "larger"
>  issues but didn't know how to directly express them, and then the replies
>  I got were immediately of a practical and mechanical nature, not
>  discussed as connected in any way to "why" (theoretical or
>  abstract-principles oriented) kinds of questions. 
> 
>  "Luke Dunstan" <coder_infidel@ho...> is the "alternate voice" in the 
>  quoted thread text which follows.
> 
>  "Paul G." <pgarceau@at...> wrote on Mon, 16 Sep 2002 04:37:26:
>  >> > > > Hi folks,
>  >> > > >
>  >> > > > Just been reviewing uname and how it is being used for
>  autoconfistication 
>  >> > > > (is that correct term?  It's the thing where "uname" is invoked 
>  from
>  >> > > > within a "./configure" script in order to determine which OS is 
>  actually running, eg: 
>  >> > > > ac_sys_system=`uname -s`)?
> 
>  "[a|A]utoconfiscation" (note the absence of a syllable present in what
>  you wrote above) is the term used for a workflow or taskset in which a
>  developer takes an existing package that does not presently have a GNU
>  Autotools-based build configuration system and supplies one. It implies
>  conversion from nothing or something other than a GNU Autotools build
>  system, to an Autotools build system. 

	Ok.

> 
>  People may sometimes speak of "autoconfiscating" a new package (that is
>  just being written), for all I know. But I haven't seen it being used
>  that way. 
> 
>  What you are talking about is referred to as determining the canonical 
>  system type. It is a step that some but not all GNU Autotools -based 
>  configure scripts accomplish via the mechanism ('uname [arg]') you've 
>  cited.

	Thank you.  That is what I was trying to get at, guess I couldn't quite "grok" it...thus 
the attempt to "grok"...

> 
>  >> > > > I am not sure why MINGW32 is coming up as part of uname -s,
>  >> > > > since MINGW32 is not really a "system".  It is closer, at least
>  >> > > > in my mind, to a type of build environment. The other half of
>  >> > > > that ("_NT-4.0" in my case) is a system reference. 
> 
>  As the rest of this thread has revolved around this question I will just
>  note for completeness that as I see it, "MSYS" is the build environment
>  and "MINGW[32]" is the *run-time* environment or "system" (the
>  terminology offered elsewhere in the thread as clarification, involving
>  "host" and "target" and "build", being crucial to bring up in making a
>  complete clarification to you in the context of *nix-like 'configure'
>  approaches).

	Ok.  Will remember that as the *shared* understanding for as long as it works.

	It does work.

> 
>  [Luke]: (no I am not quoting a book from the Bible ;-)
>  >> > > The sole purpose of MSYS is to allow MinGW to be recognised as a
>  >> > > host system by configure.
> 
>  That was well put. Without something that does what MSYS does, there
>  would be (was) no way to get a portable, GNU-style 'configure' script to
>  grasp what kind of system the software being configured was going to run
>  on (except by difficult contortions involving Cygwin's shell that
>  sometimes worked and sometimes didn't). By "system" we are talking about
>  the C runtime library and so forth: the variable,
>  platform implementation, vendor-specific "environment" that the binary
>  executable we are going to generate will have to 'interact' with. 

	Ok, so if I see MSYS_..., it is MSYS runtime we are talking about.  If it is 
MINGW32_..., it is Mingw runtime we are talking about.

	Thank you for the clarification, Soren.
> 
>  {snip}
>  >> > I think the confusion arises when I see Windows NT4 vs Mingw32. 
>  >> > Windows NT4 is an Operating System or System Platform, Mingw32 is not.  
>  Mingw32
>  >> >does, however, run on
>  >> >an NT4 platform.  Mingw32 is not a platform, is it?
> 
>  A not-merely-argumentative correction to your statement: "MinGW" 
>  applications do not *only* run (or build) on an NT4 platform.

	Accepted.  I got it.

	Practically, I count on such corrections as, **"MinGW" applications do not *only* run 
(or build) on an NT4 platform.**

	Sometimes it is difficult, at best, to simply establish such corrections.

> 
>  >> MinGW is a platform from the point of view of software, because it has
>  >> a specific runtime library that is different from other Win32
>  >> platforms such as Cygwin.
>  > 
>  >      I agree.  Mingw is a "software" platform. It is not, however, a
>  >      "system" platform. 
> 
>  At this point Paul, you just became lost in semantic abstractions.

	Ok.  Now I understand that, thanks to (and for) the non-argumentative-corrections.

> 
>  The developers of MinGW can call/describe/label it whatever they want to,
>  and the only thing that really matters from a practical perspective is
>  that all the parties concerned agree on (and sufficiently possess) a
>  common (shared) understa(nding)...

	Ok.  It is that which is what I am trying to establish here, a common (shared) 
understanding...

	Thank you, Soren for your time on this.

	Paul G.