On 10/16/17 21:13, Warren Young wrote:
On Oct 16, 2017, at 7:28 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:
I don't have the luxury of Cygwin because my end users won't have it.
You can just distribute the DLL, then.
The two programs that would need Cygwin are Fossil itself and my
application. My application is written in Tcl and is bundled into a
Starpack using a precompiled basekit. Said basekit is used both as the
interpreter stub (placed inside the Starpack) and the standalone
interpreter used to run the build script that actually creates the
first Starpack. Only in the second role does it actually need to know
anything about symlinks because they are used to define the layout of
the Starpack virtual filesystem. Should I get a custom Cygwin-capable
basekit, I'd be adding a dependency on Cygwin that complicates my
install procedure without providing any runtime benefit. Or I could
have two basekits, but that gives me an extra multi-megabyte blob
providing no capability over and above what I have right now.
Let me say that again. What I have works right now, and it's been
working ever since the early days of my project. I see zero reason to
incorporate Cygwin simply to avoid having to use the existing Fossil
emulation of symlinks which already works fine for me.
I'm curious, how far back does the Cygwin DLL work? I need to support
all the way back to Windows 2000. Actually there's one Windows 98
system, but until they fix the network on it I can't support it anyway.
Going the other direction, I think the newest system I have to support
is Windows 7, although I do test on Windows 8.1.
It's already like pulling teeth (don't get me started) to get them to
allow fossil.exe to be on the install CD
You can have an EXE but not a DLL linked to that EXE? I suppose
dynamic linkage does increase the attack surface area, but it’s a
pretty thin argument.
The end user is simultaneously paranoid about security and ignorant
about security. Please don't get me started. The whole reason I was
given this project was to deal with this fact, and thus the slightest
thing I do that they perceive as complicated (even if you and I know
it's not) will cause me to fail in my task because they decline to adopt
my solution and instead persist in manually doing the things that got
them in trouble in the first place, and we are being held responsible
for the consequences of their actions. It's not a happy situation.
Let's not discuss it further.
I'm not the one doing the reinventing.
Except you are: there are at least 4 other existing implementations of
symlinks for Windows, and you’ve just built a fifth.
No I'm not. Fossil symlinks in Windows have always been ordinary files
containing the names of their targets. That wasn't me. I'm merely
exploiting this longstanding behavior because it's straightforward and
does what I need.
No, the current behavior for native Windows Fossil is to create
ordinary files containing the name of their target (no trailing
newline).
I see why people keep trying to fix the problem, then.
Right, it's fiddly and takes great care to use properly. Changing it is
far outside the scope of my current effort. Others have already put
forward alternatives on branches, but I'm not using them. I'm sticking
with the bog-standard Fossil trunk here. I'm already taking heat for
using Fossil in the first place, even though the alternative CM system
I'm expected to use flat out doesn't work in the required development
environment. For me to not only use Fossil but also some odd branch
thereof would really push everyone over the edge.
My work is focused on reflecting the list of symlinks back into the
filesystem in the form of a manifest file. Granted, I could also have
rewritten my code to parse the manifest file actually named "manifest"
(not manifest.*) to find every line with the "l" permission, but I
already wrote my application to read a newline-delimited list of
filenames that does nothing more than list the symlinks, so I went with
that simple format.
Native Windows EXEs can call Cygwin EXEs, and vice versa. If the Tcl
code doesn’t need to follow Fossil-created symlinks, Tcl needn’t be
built under Cygwin.
The Tcl code does need to follow the symlinks. The part of it that
actually gets exposed to symlinks, I wrote to first look aside at the
symlink list file so it knows which files to treat as such. Had I used
Cygwin Fossil and Cygwin Tcl, that would all have been handled for me,
at the cost of adding a runtime dependency on Cygwin and needing custom
binaries of both that I can't be sure will work on all the required
platforms, with a benefit experienced only during the Starpack build
process that only developers will do.
Though if you wanted, the Cygwin package repository should have a wide
variety of Tcl stuff.
Not the Starpack basekits though. Getting those to work right on
Windows 2000 was enough of a chore. I don't expect Cygwin would make
that any easier.
https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks
That's a lot of complexity for something I only need during my Starpack
build process. The build process is obviously important, but reading
Fossil's emulated symlinks is a solved problem for me, so I'm not going
to incorporate Cygwin in the name of OS purity when I get 100% of my
required functionality by editing regular files.
Faking symlinks is exactly what I did all along.
Using one of the existing options is better than inventing a new one,
particularly if it’s widely recognized. By that reckoning, I’d rank
*.lnk above Cygwin symlinks in many regards. Why wouldn’t that work?
My code has to work in Linux too, and that's my preferred (though not
always available) development environment.
Why is your way superior to all of these?
I'm simply refining option #4.
No, you’re adding a new thing to the #4 bag. Not the same thing as
selecting something already in the #4 bag.
Fossil symlinks on Windows have always been plain files containing the
names of their targets. The only thing I'm adding is an optional
manifest file listing symlinks (not their targets) so that I will no
longer have to go over to a Unix system simply to ask what's a symlink
and what's not. As much as I wish I could have just stayed on Unix the
whole time, I'm stuck integrating with existing systems.
I think "s" is the best choice if it's not deemed important to use
the same letter as the manifest file uses.
Doesn’t that scheme mean you can’t have normal manifests plus symlink
manifests? Maybe you should go with “2” so that “3” = 1 | 2, giving
both files.
The manifest setting isn't a bitfield, it's a collection of flag
characters: r, u, t, and whatever we're going with symlinks. "1" is the
same as "ru", and I believe "0" is the same as empty string. To turn
everything on, set it to "rutl" or "ruts" or whatever.
--
Andy Goth | <andrew.m.goth/at/gmail/dot/com>
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
