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
