> but it is better to just use it for a few months before you try compiling
> things. Simply give up the idea of recompiling
Joseph I would very much like to build things myself from source. I have the
skills. If I could avoid ever using the prebuilt binaries, that would be nice.
Well, you have to bootstrap from something. It appears the system is designed
to bootstrap from just a working cc/ld/sh.
> You are not meant to download every single package you see on the site
Sure, I don't "have to", but I should be able to, right? As long as I stick to
source and binaries that match my system, and the "latest" of everything.
The "latest" of "everything" generally should clash, except for the possibility
of "alternatives", like..and this isn't the case with UWin/AST, but with other
systems, like there being multiple options for a Java VM or Java compiler for
example.
> There is no reason to set or change environment variables. Just leave
> everything alone as it is installed. Use it and see what you think first
> before you start mucking things up.
Not really. Imagine wanting multiple versions of tools, not accepting the
prompt to change %PATH%, and not wanting to be limited to the "shortcuts" on
the start menu.
I have a .bat file for each toolset. They work.
On the other hand, yes, sometimes using the binaries and leaving things alone
for a while first is easier, you learn it, explore it, then build it all from
source, not necessarily with any changes.
It's just that the system /appears/ to be not difficult to bootstrap. But this
could be a matter of degree and I have it /slightly/ wrong.
> Do not associate anything in cygwin with anything in UWIN
There are downloads on the site that let you chose the binaries for e.g.
Solaris, Linux, or Cygwin.i386.
There is some association. I didn't make it up. I might be confusing AST and
UWin, for sure.
- Jay
Subject: RE: [uwin-users] first impressions..Date: Thu, 10 Apr 2008 07:14:41
-0700From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[email protected]
Jay,
You seem to have some very major problems with both the AT&T web site and your
understanding of the available software.
You are not meant to download every single package you see on the site. Each
and every downloadable file serves a completely different purpose. For your
purpose, you should IGNORE anything that does not start with uwin. If you only
download uwin stuff, there is no reason to get anything else. Do not get
anything labeled anything else.
Once you get the uwin stuff, you are done. There is no reason to want to do
anything else except install the binary files. There is no reason for you to
recompile anyting. The source is there if you want to change things, but it is
better to just use it for a few months before you try compiling things. Simply
give up the idea of recompiling. It serves no purpose. The software already
works “out of the box”.
There is no reason to set or change environment variables. Just leave
everything alone as it is installed. Use it and see what you think first
before you start mucking things up.
UWIN is a complete ast-based environment. It starts with ast and includes all
ast-based utilities, including ksh. It is a complete environment. Nothing
else is required. Cygwin is a giant pile of linux and has no relation to
anything in UWIN. Do not associate anything in cygwin with anything in UWIN.
Remove cygwin from your system and you will be better off.
/Jow
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JaySent:
Thursday, April 10, 2008 5:45 AMTo: David Korn; [EMAIL PROTECTED]: RE:
[uwin-users] first impressions..
David, thanks for replying. realize: I am a potential user of both AST and/or
UWin. I am not sure which is which, and I don't think that is terrible. I
added myself to "all" the lists.I guess UWin is posix.dll and pthreads.dll.AST
is ksh and Graphvis and CDT.UWin is stuff exclusively for Windows.AST is stuff
on top of UWin and top of "native Unix". I said the package collection is NOT
huge, but I was unclear.What do you consider "Cygwin" binaries vs. non-Cygwin
Windows binaries?I guess you consider "native UWin" to be like, any of a
varietyof Win32 toolsets? Whatever your cc wraps? Pardon me for merging
multiple toptics into one mail, here goes:Your cc didn't find my cl.Here are
more strategies:Imaginea) At every opportunity where setup asked to set some
variables, I declined.b) or after running setup, I clean installed the
OS.and/orc) I have my own .bat files that establish %PATH%/%LIB%/%INCLUDE% Some
implications:Various versions of Visual C++ have unique variables, besides
thecommon PATH/LIB/INCLUDE. While I clear those after setup, they arenot
unreasonable to depend upon.Here is my prototype Python code (You can find this
via modula3.elegosoft.com) VCBin = "" VCInc = "" VCLib =
"" MspdbDir = "" # 4.0 e:\MSDEV # 5.0 E:\Program
Files\DevStudio\SharedIDE MSDevDir = os.environ.get("MSDevDir") #
5.0 MSVCDir = os.environ.get("MSVCDir") # E:\Program Files\DevStudio\VC
# 7.1 Express VCToolkitInstallDir =
os.environ.get("VCToolkitInstallDir") # E:\Program Files\Microsoft Visual C++
Toolkit 2003 (not set by vcvars32) # 8.0 Express # E:\Program
Files\Microsoft Visual Studio 8\VC # E:\Program Files\Microsoft Visual
Studio 8\Common7\Tools DevEnvDir = os.environ.get("DevEnvDir") #
E:\Program Files\Microsoft Visual Studio 8\Common7\IDE VSInstallDir =
os.environ.get("VSINSTALLDIR") # E:\Program Files\Microsoft Visual Studio 8
# VS80CommonTools = os.environ.get("VS80COMNTOOLS") # E:\Program
Files\Microsoft Visual Studio 8\Common7\Tools VCInstallDir =
os.environ.get("VCINSTALLDIR") # E:\Program Files\Microsoft Visual Studio 8\VC
# # This is not yet finished. # # Probe the partly
version-specific less-polluting environment variables, # from newest to
oldest. # That is, having setup alter PATH, INCLUDE, and LIB system-wide
is not # a great idea, but having setup set DevEnvDir, VSINSTALLDIR,
VS80COMNTOOLS, etc. # isn't so bad and we can temporarily establish the
first set from the second # set. # if VSInstallDir:
# # Visual C++ 2005/8.0, at least the Express Edition, free
download # if not VCInstallDir:
VCInstallDir = os.path.join(VSInstallDir, "VC") if not DevEnvDir:
DevEnvDir = os.path.join(VSInstallDir, "Common7", "IDE")
MspdbDir = DevEnvDir elif VCToolkitInstallDir: # #
free download Visual C++ 2003; no longer available #
VCInstallDir = VCToolkitInstallDir elif MSVCDir and MSDevDir:
# # Visual C++ 5.0 # pass # do more research
# VCInstallDir = MSVCDir elif MSDevDir: #
# Visual C++ 4.0, 5.0 # pass # do more research
# VCInstallDir = MSDevDir else: # # This is what
really happens on my machine, for 8.0. # It might be good to guide
pylib.py to other versions, # however setting things up manually
suffices and I have, um, # well automated. #
Msdev = os.path.join(SystemDrive, "msdev", "80") VCInstallDir =
os.path.join(Msdev, "VC") DevEnvDir = os.path.join(Msdev, "Common7",
"IDE") if VCInstallDir: VCBin = os.path.join(VCInstallDir,
"bin") VCLib = os.path.join(VCInstallDir, "lib") VCInc =
os.path.join(VCInstallDir, "include") if DevEnvDir: MspdbDir
= DevEnvDir #elif VCBin: # MspdbDir = VCBin
_SetupEnvironmentVariableAll("INCLUDE", ["errno.h"], VCInc)
_SetupEnvironmentVariableAll( "LIB", ["kernel32.lib",
"libcmt.lib"], VCLib + os.path.pathsep + os.path.join(InstallRoot,
"lib")) # # Do this before mspdb*dll because it sometimes gets it
in the path. # _SetupEnvironmentVariableAll("PATH", ["cl",
"link"], VCBin) _SetupEnvironmentVariableAny( "PATH",
["mspdb80.dll", "mspdb71.dll", "mspdb70.dll", "mspdb60.dll", "mspdb50.dll",
"mspdb41.dll", "mspdb40.dll", "dbi.dll"], MspdbDir)
_SetupEnvironmentVariableAny( "PATH", ["msobj80.dll",
"msobj71.dll", "msobj10.dll", "msobj10.dll", "mspdb50.dll", "mspdb41.dll",
"mspdb40.dll", "dbi.dll"], MspdbDir) # # The free
Visual C++ 2003 has neither delayimp.lib nor msvcrt.lib. # Very old
toolsets have no delayimp.lib. # The Quake config file checks these
environment variables. # Lib = os.environ.get("LIB") if
not SearchPath("delayimp.lib", Lib): os.environ["USE_DELAYLOAD"] =
"0" if not SearchPath("msvcrt.lib", Lib):
os.environ["USE_MSVCRT"] = "0"_SetupEnvironmentVariableAll checks if all the
listed files are in the variable, else adds the
parameter._SetupEnvironmentVariableAny checks if any are, and if not, adds. def
_SetupEnvironmentVariableAll(Name, RequiredFiles, Attempt): AnyMissing =
False Value = os.environ.get(Name) if Value: for File in
RequiredFiles: if not SearchPath(File, Value):
AnyMissing = True break else: AnyMissing = True if
AnyMissing: if Value: NewValue = Attempt + os.path.pathsep +
Value else: NewValue = Attempt for File in
RequiredFiles: if not SearchPath(File, NewValue):
print("ERROR: " + File + " not found in " + _FormatEnvironmentVariable(Name) +
"(" + NewValue + ")") sys.exit(1) os.environ[Name] =
NewValue if Value: print(Name + "=" + Attempt + os.pathsep +
_FormatEnvironmentVariable(Name)) else: print(Name + "=" +
Attempt)def _SetupEnvironmentVariableAny(Name, RequiredFiles, Attempt):
Value = os.environ.get(Name) if Value: for File in RequiredFiles:
if SearchPath(File, Value): return if Value:
NewValue = Attempt + os.path.pathsep + Value else: NewValue = Attempt
for File in RequiredFiles: if SearchPath(File, NewValue):
os.environ[Name] = NewValue if Value: print(Name +
"=" + NewValue + os.pathsep + _FormatEnvironmentVariable(Name))
else: print(Name + "=" + NewValue) return
print("ERROR: " + _FormatEnvironmentVariable(Name) + " does not have any of " +
" ".join(RequiredFiles)) sys.exit(1)##
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52224#def
SearchPath(name, paths = getenv("PATH")): #Given a search path, find file
if (name.find("/") != -1) or (name.find("\\") != -1): if
os.path.isfile(name): return name if paths == "": return
None (base, exts) = os.path.splitext(name) if not exts: exts =
(getenv("PATHEXT") or "").lower() for ext in exts.split(";"): if ext
== ".": ext = "" name = (base + ext) for path in
paths.split(os.path.pathsep): candidate = os.path.join(path, name)
if os.path.isfile(candidate): return
os.path.abspath(candidate)So this is two strategies in one: search %PATH% for
cl.exe, link.exe, etc., and if not found, look in some other environment
variables.As well, check the default install locations.I don't have all that
data collected, but like%systemdrive%:\dm for digital
mars.%systemdrive%:\program files\blahblah for Visual C++I install Metrowerks
(don't use it much) to \mwerks\6, \mwerks\7, but that's me.Visual C++ to
\msdev\40, \msdev\50, \msdev\60, \msdev\70, \msdev\80, etc., also just me.SO
you are saying if I setup things so that cc/ld find cl/link, I can just build X
from source?A particular branch?The Cygwin stuff builds from a particular
branch I think.There is some overlap of packages and it is confusing.CDT is
available as a separate download, but appears old.And it is part of other
packages, up to date?? > The "cygwin.i386" binaries have nothing to do with
UWIN. The cygwin.i386> is a compilation of the AST software for Cygwin. UWIN
contains> a compilation of this for UWIN as well as many other commands that>
are not part of AST. I'm not stupid..but I am a bit confused.The downloads are
all together. I understand UWin is a Unix portability layer akin to Cygwin.And
AST is a bunch of "apps", like Graphviz, not a portability layer.You'd build it
on Cygwin or UWin, maybe either works similarly.But UWin I think has a "better"
license.The UWin and AST downloads are in the same place and I'd rather hope
that folks (you) knowledgable about one, are also knowledable about the
other... - Jay
> Date: Wed, 9 Apr 2008 10:10:34 -0400> From: [EMAIL PROTECTED]> To: [EMAIL
> PROTECTED]; [email protected]> Subject: Re: [uwin-users] first
> impressions..> > cc: [EMAIL PROTECTED]> Subject: Re: [uwin-users] first
> impressions..> --------> > First, thanks for the feedback.> > I spent just a
> small amount of time trying to use/install/build uwin/ast.> > My experience
> was good and bad.> > I'm mainly a Win32 user and that's what I used.> > The
> base Win32 binary installer + X Windows installers work.> > I would prefer a
> somewhat smaller base -- like maybe no services.Or prompting. I> > was
> surprised good and bad to see sshd running.> > I would prefer that the
> install not deny me access to some of the files.But that> > is easily fixed.
> I take ownership and then reacl.> > > > The /apparent/ but not yet realized
> by me ease of building the system from sourc> > e, esp. from just
> sh+ratz+package, is attractive.> > > > The /apparent/ but not yet clear to me
> more liberal license than that of Cygwin > > is attractive (below).> > > >
> That it includes an X Windows server is somewhat attractive. I have some X
> code > > I'd like to try on Windows.> > Ok, now my big complaints:> > 1)
> several packages appear to be out of date.Some packages have no source
> distri> > bution. For example mawl. For example X Windows. cdt appears old.>
> Since mawl is not part of UWIN, I assume that you are talking about> other
> packages on the site; not just UWIN. UWIN has a recent version of> cdt as
> part of the ast library and is in src/lib/libast/cdt in the> source code. The
> X-Windows package was built from a download of> the X11R6.6 source several
> months ago.> > It sounds like some of the source archives overlap, but I
> don'tthink the overlap> > ping ones had the same dates.> > Given that there
> aren't a HUGE number of packages, some "all" option would be ni> > ce.> UWIN
> does not have a huge number of packages. There are the following:> base>
> developement> x11base> x11development> groff> perl> The base package contains
> the AST software which contains many libraries such as vcodex and cdt.> > > >
> 2) Attempting to build the system from source appears to lead to much
> different> > results than that the installer produces. Besides that I got
> compilation error> > s that I haven't dug into yet, the file system layout is
> different. This seems > > wrong.> > The binaries claim to be for a
> "cygwin.i386" flavor.I don't quite get the relati> > onship between uwin and
> cygwin.I get, sure, that cygwin can be used to bootstrap> > using
> ratz/package.I get, sure, that uwin doesn't really include a compiler, po> >
> ssibly a good thing.But, e.g. being "cygwin" implies a possible cygwin1.dll
> depe> > ndency.> The "cygwin.i386" binaries have nothing to do with UWIN. The
> cygwin.i386> is a compilation of the AST software for Cygwin. UWIN contains>
> a compilation of this for UWIN as well as many other commands that> are not
> part of AST.> > The directions are not clear as to if I must alter
> %PATH%.They have some wierd w> > ording about some things requiring it.Is the
> point, like, if I use nmake, I need> > to alter %PATH%?And it is just..I
> installed to \uwin...\uwin\arch\cygwin.i386 o> > r such?I forget now if the X
> binaries were there -- but actually, the X binaries> > have no source, so I
> they were installed with a binary installer, whichputs the > > files
> elsewhere entirely.> We will post at least the changes we made to the X11
> sources.> > I don't think I ever found a short summary of the license.That
> would be nice.> Here is a short summary:> 1. Don't sue us.> 2. If you
> distribute, make it clear to anyone that AT&T has no> liability.> 3. If you
> make changes to source code in any of our modules and> distriubte, you must
> make this changes available as well.> 4. You can add new modules that are
> proprietary and distribute.> > I will fiddle around more here.I realize my
> report here is all very unscientific> > and devoid of details.> > uwin looks
> like a good alternative to Cygwin.I'll have to find how it implements> >
> fork/vfork/exec, see if it isefficient unlike Cygwin (I get that fork would
> be > > quite difficult, butvfork+exec maybe not..)> UWIN implements fork() as
> well as vfork(). Actually, exec was harder to> implement than fork().> > Do
> you have any AMD64 (or IA64?) Windows versions?> We expect to build a 64 bit
> version some time this year.> > - Jay> > (attachment 1 66/3194 text/html
> "1.att")> > > > _______________________________________________> > uwin-users
> mailing list> > [email protected]> >
> https://mailman.research.att.com/mailman/listinfo/uwin-users> > > > David
> Korn> [EMAIL PROTECTED]_______________________________________________
uwin-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/uwin-users
