On 7/25/2013 07:46, Jan Nijtmans wrote:
2013/7/25 Richard Hipp <[email protected]>:
If it does work, then I move for the immediate banishment of all __CYGWIN__
macros.
Doing that will break four things:
- Accessing a check-out repository on Cygwin, while the previous check-out
was done in win32.
Are you merely predicting this, or are you reporting that you've tried
it and found that it does break when you do this?
I don't recall seeing any __CYGWIN__ protected code blocks on my
spelunking trip -- reported to the list earlier -- that would cause such
an incompatibility.
- Allow usage of win32 paths (possibly coming from WIN32 variables) in fossil.
What are you talking about? Fossil's __CYGWIN__ protected code blocks
don't affect how the Cygwin DLL interprets file paths.
- Cygwin doesn't allow '\' in paths like UNIX does, or the behavior of
UNC paths.
Ditto.
- Cooperation of Cygwin with windows programs using sqlite (like TortoiseSVN)
What problem are you actually envisioning here? There is no
TortoiseFossil to cause problems in this case.
If someone builds a pure Cygwin fossil.exe without the __CYGWIN__ blocks
enabled, what native Windows program runs to break the Cygwin fossil.exe?
If there is such a problem, the fix is simple:
./configure --disable-internal-sqlite
Then it builds against my Cygwin SQLite library, which *does* cope with
the problems you're thinking of.
If you build Fossil with all the __CYGWIN__ blocks disabled and use the
internal SQLite, it should behave as if linking to Cygwin SQLite
3.7.17-3+ with the POSIX advisory locking mode enabled. That's
perfectly fine if you don't need the SQLite DB file to be accessible
from a native Windows SQLite based program at the same time.
this only works on Cygwin > 1.7.20
That isn't a problem in the Cygwin SQLite package, since you have to go
out of your way to update the SQLite package only, without updating the
Cygwin DLL, too.
I can understand if the SQLite developers want to hold off adopting this
patch into the shipped version of SQLite. They may have Cygwin based
customers who don't keep their Cygwin installations up to date. Plus,
I'd like to see this mandatory locking feature get more than a month of
use before all the __CYGWIN__ blocks get ripped out of upstream SQLite.
Once we're sure the new Cygwin DLL based locking works just as well as
the stuff we've replaced, I'd be happy to see upstream adopt this patch.
and it doesn't follow the SQLite coding
style, so it will need some more work.
I tried to write the patch to blend into the surrounding code.
I've just noticed the spaces-vs-tabs difference, which I've fixed in my
local copy.
Is there anything more substantial that needs changing?
Perhaps you don't like my enum naming scheme, or the fact that I used an
enum for my constants instead of preprocessor macros.
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
