Re: [fossil-users] Fossil on cygwin64

[Warren Young]

On 7/26/2013 01:15, Jan Nijtmans wrote:


For your other remarks, I suggest that you become a fossil
code committer.


I've yet to step beyond evaluating Fossil for use here.  I like its 
features and how it works, but I think I'm going to be forced to use git 
for interoperability reasons.  (We're currently using svn, and need to 
step into the DVCS world soon.)


Even if we did choose Fossil, we'd be using it on Linux, for the vast 
majority of checkins.  Checkins from the Cygwin side would be under 1% 
of all our use.


Bottom line, I'd have little personal stake in these patches. 
Half-hearted patches make for bad code.


All I'm doing here in this thread is evaluating whether these existing 
code blocks make sense for Cygwin, and suggesting alternatives where 
they don't make sense.  Someone who actually cares how and whether 
Fossil works on Cygwin should be doing the patches.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Jan Nijtmans]

2013/7/26 Warren Young :
> db.c, db_open(): Wrong.  Fix or remove.
>
> First, hard-coding a conversion to "/cygdrive/%c/%s" will break if the user
> has changed the cygdrive mount point in /etc/fstab.  This is more common
> than you may realize.  If you mount cygdrive at the root, you can use
> shorter quasi-DOS paths like /c/Windows.  I use this feature.

You are absolutely right. Fixed now in:
   
Forgot that there already was a function doing that, this was an
ill-thought code duplication. Thanks!

For your other remarks, I suggest that you become a fossil
code committer. See:

That makes it easier to discuss any suggestions you have, so they
eventually can find their way into trunk. As you are the Cygwin SQLite
package maintainer that would be a logical step.

Regards,
   Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Warren Young]

Some of what I wrote was based on wrong assumptions due to being stuck 
here on a February branch of Fossil's repo.  Now that I've looked at the 
__CYGWIN__ blocks in an up-to-date Fossil trunk, I understand your post 
better, Jan.  Updated commentary inline below.



On 7/25/2013 15:59, Warren Young wrote:

On 7/25/2013 07:46, Jan Nijtmans wrote:

2013/7/25 Richard Hipp :

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.


I proposed two fixes for this in my second spelunking report.  (My 
improved algorithm for finding _fossil, and the FOSSILDB feature.)



- Allow usage of win32 paths (possibly coming from WIN32 variables) in
fossil.


For the most part, Fossil shouldn't be caring as much about path details 
as it currently does.  Most programs just blindly throw paths at the OS, 
and let it deal with it.


To the extent that Fossil *does* have to care, it shouldn't try to fix 
backslashes or drive letters for Cygwin users.  The Cygwin DLL does this 
already, albeit with a warning.  Duplicating the functionality in Fossil 
is wrongheaded, for the same reason you don't duplicate functionality in 
any other program.



 ./configure --disable-internal-sqlite

Then it builds against my Cygwin SQLite library, which *does* cope with
the problems you're thinking of.


I see that this doesn't work right now, because I hadn't yet shipped 
3.7.17-3 for Cygwin64.  I'm working on fixing that now.



I've just noticed the spaces-vs-tabs difference, which I've fixed in my
local copy.


This will appear in my 64-bit packages.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Warren Young]

On 7/24/2013 05:06, Warren Young wrote:

On 7/24/2013 02:33, Jan Nijtmans wrote:

Just wait on the Cygwin64 people to bring out a new Sqlite package with
the same fixes already done in Cygwin32.


Um, it's the same people.  Me. :)


Oh, I see what you mean.  I forgot that I didn't release 3.7.17-3 for 
64-bit as well.  You're the first person to ask, and it was so obliquely 
that I didn't realize it at first. :)


I'll be RFU'ing 3.7.17-3 for Cyginw64 soon.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Warren Young]

On 7/25/2013 16:52, Joe Mistachkin wrote:


Warren Young wrote:


I guess they already got taken out of the trunk.  I did my spelunking in
a current pull of the tree.


I'm simply searching trunk for "__CYGWIN__".


I was stuck on a branch from February. 

Now that I'm actually looking at the trunk, back into the cave we go:


add.c, line 25: You should be #including windows.h here instead of 
providing these prototypes.  That makes Cygwin's w32api package a build 
dependency, but if fossil.exe is going to do registry API calls when 
built with Cygwin, that seems a reasonable dependency.


add.c, filenames_are_case_sensitive(): Keep it.  The Cygwin registry 
setting *is* a better default here than the Unix case default.




blob.c, blob_write_to_file(): Why not let the OS catch this error?  I'd 
take this test out for native Windows, too.



blob.c, BOM and UTF-16 awareness: I think this code is well-intentioned 
for Cygwin, but probably not quite right.


For Cygwin, you should probably assume UTF-8 by default, as for any 
modern *ix.  Text editors under Cygwin default to UTF-8, not UTF-16 as 
do native Windows Unicode text editors.  If there is a BOM, you should 
probably do the conversion from UTF-16 to UTF-8 on all platforms, not 
just Windows and Cygwin.




checkin.c, commit_warning(): Really?  Why can't you use iconv(3)?



db.c, db_open(): Wrong.  Fix or remove.

First, hard-coding a conversion to "/cygdrive/%c/%s" will break if the 
user has changed the cygdrive mount point in /etc/fstab.  This is more 
common than you may realize.  If you mount cygdrive at the root, you can 
use shorter quasi-DOS paths like /c/Windows.  I use this feature.


Second, if Fossil really must mung Windows drive paths to POSIX paths on 
Cygwin instead of passing paths blindly to the OS like any other program 
would, it should be done at a higher level than the DB layer.


If you really must mung paths, ask the Cygwin DLL to do it for you, via 
cygwin_conv_path().  This fixes the cygdrive mount point problem, too.


Personally, I'd say remove the ifdef entirely.



db.c, db_open_config(), user DB location:  This function has its heart 
in the right place, but it's awfully brittle.


Consider just the native Windows case.  If, the first time you run 
Fossil, LOCALAPPDATA isn't defined, it will put the DB in %APPDATA%. 
But if LOCALAPPDATA is then later defined, it doesn't continue searching 
the fall-back hierarchy to find its earlier DB file.  It will create a 
new one in %LOCALAPPDATA% and ignore the one it created earlier, losing 
any settings you had.


The following algorithm provides proper fall-back behavior for native 
Windows and ensures that pure Cygwin users get the ~/.fossil file they 
expected:


1. Search the three native Windows environment variable directories for 
_fossil, using the first one found.


2. If none are found and this is Cygwin, try ~/.fossil, too.

3. If the DB still isn't found, create a new one in ~/.fossil if this is 
Cygwin, or in %FOO%/_fossil on native Windows, where %FOO% is the 
highest-precedence environment variable found.


Alternatively, add a feature to Fossil that lets you override the 
hard-coded DB file location(s) with a high-precedence environment 
variable.  (That is, a second EV on Unix, and a fourth on Windows.) 
Say, FOSSILDB.  Then you can set it to c:\cygwin\home\foo to get 
interoperability between native and Cygwin fossil.exe.  There might be 
Unix users who can find a use for this feature, too.




db.c, db_open_config(), '.' -> '_' smashing: Cargo cult detected.

Windows NT derivatives and programs written with NT-derived OSes in mind 
treat files with a leading dot like any other file.  The only programs 
that don't are those that insist on having a file name extension -- 
which shouldn't be given .fossil files to begin with -- and programs 
with DOS/Win9x heritages.


Cygwin dropped Win9x support in 2009.  Microsoft dropped Win9x support 
in 2006.  DOS and Win16 compatibility got dropped for 64-bit systems in 
Vista, in 2007.  We no longer need to pussy-foot around leading dots on 
Windows in 2013.


The comment claims "some window systems [have] problems" with file names 
beginning with a dot.  Are any of these systems still supported by 
Microsoft?  And, "many apps" have problems?  Quantify "many".  If 
nonzero, how many of these require access to Fossil DB files?




db.c, cmd_open(): Same as above.

For that matter, I think Fossil 2.0 should use .fslckout on native 
Windows, too, and avoid the need for any special-casing here at all. 
(Why 2.0?  It's a breaking change, so it shouldn't be done lightly.)




db.c, db_open_config(), file access test: This should be unconditional, 
or be removed.  Unix gets by without it, so there must be some higher 
level code that checks whether the DB was opened for writing.


Surely "chmod 400 ~/.fossil" is a problem on Unix, too?



db.c, db_open_repository(): Another bogus /cygdrive hack.  Remove or 
replace with a cygw

Re: [fossil-users] Fossil on cygwin64

[Joe Mistachkin]

Warren Young wrote:
> 
> I guess they already got taken out of the trunk.  I did my spelunking in 
> a current pull of the tree.
> 

I'm simply searching trunk for "__CYGWIN__".

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Warren Young]

On 7/25/2013 16:03, Joe Mistachkin wrote:


Warren Young wrote:


I'm up for some spelunking.  Let's go:



What about all the __CYGWIN__ blocks in the following files?


I guess they already got taken out of the trunk.  I did my spelunking in 
a current pull of the tree.


That explains why Richard referred to "8 files" having CYGWIN blocks, 
but I found only 7.  He must have been referring to src/* only.


I assume that whoever removed these blocks did the same sort of analysis 
I did for those outside the src subtree, and determined that they were 
in fact pointless.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Warren Young]

On 7/25/2013 04:29, Richard Hipp wrote:

Native, pure-blooded windows binaries run just fine on cygwin, right?


Mostly, yes.

There are exceptions.  The Windows console infrastructure isn't as 
general and as easy to hook into a the Unix TTY equivalent, so there are 
programs that only work properly in a native Windows console.  Programs 
in this class typically fail when run in mintty, or under screen, or via 
Cygwin ssh.



So why are we complicating the code with exceptions, special cases, and
hacks for cygwin?


Ideally, Cygwin should be treated as just another Unix-like OS.

Unfortunately, it runs on top of a Windows kernel, which simply doesn't 
do some things in a way that allows it to provide proper POSIX/Linux 
semantics.  Over time, Cygwin has gotten better at patching over these 
differences, but some are intractable enough that they remain.  Part of 
the problem is a need to continue working with the native Windows side 
of things.


The mandatory vs advisory file locking stuff is a good example.  I 
assume you're aware -- at least peripherally -- of the changes that 
happened to Cygwin SQLite recently.  It's all an attempt to paper over 
yet another of these differences between Windows and POSIX semantics.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Joe Mistachkin]

Warren Young wrote:
>
> I'm up for some spelunking.  Let's go:
>

What about all the __CYGWIN__ blocks in the following files?

1. add.c
2. blob.c
3. checkin.c
4. db.c
5. file.c
6. utf8.c

Frankly, I'm not convinced of how many of these are actually necessary.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Warren Young]

On 7/25/2013 07:46, Jan Nijtmans wrote:

2013/7/25 Richard Hipp :

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
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Martin Gagnon]

On Thu, Jul 25, 2013 at 02:42:23PM -0600, Warren Young wrote:
> On 7/25/2013 06:24, Jan Danielsson wrote:
> >So .. we used the __CYGWIN__ macro to explicitly break fossil on
> >cygwin? That seems unnecessarily creative to me.
> 
> It is well known that the creators of Cygwin do this sort of thing
> because They're Just Mean.  Maybe Fossil's creators are the same
> way?
> 
> >Out of curiosity (there must be one or two here who put them there):
> >What are/were their intended purposes [in the fossil code]?
> 
> I'm up for some spelunking.  Let's go:
> 
> compat/zlib/gzguts.h: Forces HAVE_VSNPRINTF to true.  This sounds
> like a configure script bug to me.  If it's fixed now, the ifdef
> should go.  If vsnprintf() is still not being detected on Cygwin,
> that problem  should be corrected at its source, not hacked around
> like this.
> 
> compat/zlib/contrib/inflate86/inffast.S: ELF vs. COFF executable
> format inference, to provide the leading underscore MS linkers want.
> Since the resulting binary works, one of the following must be true:
> 
>   a) Fossil is using the plain C version, not the optimized assembly; or
>   b) the Cygwin linker now copes with this difference; or
>   c) WIN32 is somehow getting defined by this point, so the
> __CYGWIN__ test is redundant.
> 
> compat/zlib/contrib/puff/pufftest.c, compat/zlib/{examples,test}/*:
> Example code that came with zlib, so it doesn't matter if it doesn't
> build and work correctly.
> 
> compat/zlib/zutil.h: This seems bogus.  The way it's coded implies
> that "WIN32" is defined when __CYGWIN__ is, which isn't currently
> true, unless you pass -mwin32 to the compiler, which you shouldn't
> in this case.  However, if I'm wrong, and WIN32 *is* somehow being
> defined here, the test is appropriate and shouldn't be removed: zlib
> blobs created under Cygwin *should* be marked as having been created
> "on Unix" rather than "on Win32".
> 
> src/sqlite3.c: __CYGWIN__ stuff to be removed through other channels. :)
> 
> src/th_tcl.c: Not sure if this one can go or not.  It might depend
> on whether your Fossil is linking to a Cygwin Tcl or the native
> Windows Tcl.  Lluís, if you're reading this, did you test TH1 under
> Cygwin? Which Tcl is your fossil.exe linked to?  (Ask ldd if you're
> not sure.)

I'm wondering, why someone would want to build cygwin version of fossil
and link with native TCL and vice-versa ?  When you build cygwin
version, you can have everything you need in cygwin version under the
cygwin tree. Tyring to mixte native and cygwin stuff here is looking for
trouble.

If you use mingw toolchain inside cygwin to produce native Windows
binary, it's another story, (this is like cross compiling) and in that
case, __CYGWIN__ should not be defined at all and this should behave
exactly like building directly fossil on a mingw/msys setup using the
Makefile.mingw.  Exactly like cross-compiling mingw apps under FreeBSD
or Linux.

(I don't know how the ./configure script deal with cross-compiling)


-- 
Martin G.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Warren Young]

On 7/25/2013 06:24, Jan Danielsson wrote:

So .. we used the __CYGWIN__ macro to explicitly break fossil on
cygwin? That seems unnecessarily creative to me.


It is well known that the creators of Cygwin do this sort of thing 
because They're Just Mean.  Maybe Fossil's creators are the same way?



Out of curiosity (there must be one or two here who put them there):
What are/were their intended purposes [in the fossil code]?


I'm up for some spelunking.  Let's go:

compat/zlib/gzguts.h: Forces HAVE_VSNPRINTF to true.  This sounds like a 
configure script bug to me.  If it's fixed now, the ifdef should go.  If 
vsnprintf() is still not being detected on Cygwin, that problem  should 
be corrected at its source, not hacked around like this.


compat/zlib/contrib/inflate86/inffast.S: ELF vs. COFF executable format 
inference, to provide the leading underscore MS linkers want.  Since the 
resulting binary works, one of the following must be true:


  a) Fossil is using the plain C version, not the optimized assembly; or
  b) the Cygwin linker now copes with this difference; or
  c) WIN32 is somehow getting defined by this point, so the __CYGWIN__ 
test is redundant.


compat/zlib/contrib/puff/pufftest.c, compat/zlib/{examples,test}/*: 
Example code that came with zlib, so it doesn't matter if it doesn't 
build and work correctly.


compat/zlib/zutil.h: This seems bogus.  The way it's coded implies that 
"WIN32" is defined when __CYGWIN__ is, which isn't currently true, 
unless you pass -mwin32 to the compiler, which you shouldn't in this 
case.  However, if I'm wrong, and WIN32 *is* somehow being defined here, 
the test is appropriate and shouldn't be removed: zlib blobs created 
under Cygwin *should* be marked as having been created "on Unix" rather 
than "on Win32".


src/sqlite3.c: __CYGWIN__ stuff to be removed through other channels. :)

src/th_tcl.c: Not sure if this one can go or not.  It might depend on 
whether your Fossil is linking to a Cygwin Tcl or the native Windows 
Tcl.  Lluís, if you're reading this, did you test TH1 under Cygwin? 
Which Tcl is your fossil.exe linked to?  (Ask ldd if you're not sure.)

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

On Thu, Jul 25, 2013 at 03:46:21PM +0200, Jan Nijtmans wrote:
> 2013/7/25 Richard Hipp :
> > 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.
> - Allow usage of win32 paths (possibly coming from WIN32 variables) in fossil.
> - Cygwin doesn't allow '\' in paths like UNIX does, or the behavior of
> UNC paths.
> - Cooperation of Cygwin with windows programs using sqlite (like TortoiseSVN)

As a cygwin user, this breakage is what I expect by any cygwin version of a
program, be it fossil, mercurial, git, vim, ...

I'd never use a cygwin-git checkout with non-cygwin-git, for example. I never
tried and i would not expect it to work.

> > If it doesn't work, is that a bug in cygwin?
> 
> More likely, it's a limitation of Cygwin running on Windows.
> 
> Not seconded.
> 
> In SQLite various __CYGWIN__ #ifdef's can be removed if another locking
> mechanism is put in place. Attached is the current patch the Cygwin
> people use for their build of SQLite accomplishing this. But this only
> works on Cygwin > 1.7.20, and it doesn't follow the SQLite coding
> style, so it will need some more work.

I have no idea how locking has to be handled in cygwin, but if the issue is at
using a sqlite db with both cygwin and non-cygwin programs, this is a tricky
thing.

As for me, I don't expect cygwin programs' data to cope well with windows
programs' data.

Regards,
Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Jan Nijtmans]

2013/7/25 Richard Hipp :
> 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.
- Allow usage of win32 paths (possibly coming from WIN32 variables) in fossil.
- Cygwin doesn't allow '\' in paths like UNIX does, or the behavior of
UNC paths.
- Cooperation of Cygwin with windows programs using sqlite (like TortoiseSVN)

> If it doesn't work, is that a bug in cygwin?

More likely, it's a limitation of Cygwin running on Windows.

Not seconded.

In SQLite various __CYGWIN__ #ifdef's can be removed if another locking
mechanism is put in place. Attached is the current patch the Cygwin
people use for their build of SQLite accomplishing this. But this only
works on Cygwin > 1.7.20, and it doesn't follow the SQLite coding
style, so it will need some more work.

Regards,
  Jan Nijtmans


sqlite3-3.7.17-3.src.patch
Description: Binary data
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Jan Danielsson]

On 7/25/13 2:10 PM, Richard Hipp wrote:
> Move to banish __CYGWIN__ from both Fossil and SQLite sources.  Do I have a
> second?

   Seconded.

   /Jan

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Jan Danielsson]

On 7/25/13 2:05 PM, Lluís Batlle i Rossell wrote:
[---]
>> "grep" tells me that there are 33 instances of the __CYGWIN__ macro in
>> Fossil, in 8 different files.  So if you use "sed" to change them all to
>> __CYGWIN_OFF_ (or something else harmless) and then do "./configure; make",
>> does it work?   (I don't have cygwin installed so this is not something I
>> can easily test.)
>>
>> If it does work, then I move for the immediate banishment of all __CYGWIN__
>> macros.
> 
> fossil clone in cygwin64 now works perfectly:

   So .. we used the __CYGWIN__ macro to explicitly break fossil on
cygwin? That seems unnecessarily creative to me.

   Out of curiosity (there must be one or two here who put them there):
What are/were their intended purposes [in the fossil code]?

   /Jan

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Richard Hipp]

On Thu, Jul 25, 2013 at 8:05 AM, Lluís Batlle i Rossell wrote:

> On Thu, Jul 25, 2013 at 07:59:38AM -0400, Richard Hipp wrote:
> > On Thu, Jul 25, 2013 at 7:44 AM, Martin Gagnon  wrote:
> >
> > >  In Theory, fossil should build and work on fossil like on any other
> unix
> > > like Operating system (like linux/*bsd etc..) That's what cygwin is
> for.
> > >
> >
> > "grep" tells me that there are 33 instances of the __CYGWIN__ macro in
> > Fossil, in 8 different files.  So if you use "sed" to change them all to
> > __CYGWIN_OFF_ (or something else harmless) and then do "./configure;
> make",
> > does it work?   (I don't have cygwin installed so this is not something I
> > can easily test.)
> >
> > If it does work, then I move for the immediate banishment of all
> __CYGWIN__
> > macros.
>
> fossil clone in cygwin64 now works perfectly:
> $ sed s/__CYGWIN__/__CYGWIN__OFF__/ -i src/*
> $ ./configure
> $ make -j4
>

Move to banish __CYGWIN__ from both Fossil and SQLite sources.  Do I have a
second?

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

On Thu, Jul 25, 2013 at 07:59:38AM -0400, Richard Hipp wrote:
> On Thu, Jul 25, 2013 at 7:44 AM, Martin Gagnon  wrote:
> 
> >  In Theory, fossil should build and work on fossil like on any other unix
> > like Operating system (like linux/*bsd etc..) That's what cygwin is for.
> >
> 
> "grep" tells me that there are 33 instances of the __CYGWIN__ macro in
> Fossil, in 8 different files.  So if you use "sed" to change them all to
> __CYGWIN_OFF_ (or something else harmless) and then do "./configure; make",
> does it work?   (I don't have cygwin installed so this is not something I
> can easily test.)
> 
> If it does work, then I move for the immediate banishment of all __CYGWIN__
> macros.

fossil clone in cygwin64 now works perfectly:
$ sed s/__CYGWIN__/__CYGWIN__OFF__/ -i src/*
$ ./configure
$ make -j4

Thank you! :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Richard Hipp]

On Thu, Jul 25, 2013 at 7:44 AM, Martin Gagnon  wrote:

>  In Theory, fossil should build and work on fossil like on any other unix
> like Operating system (like linux/*bsd etc..) That's what cygwin is for.
>

"grep" tells me that there are 33 instances of the __CYGWIN__ macro in
Fossil, in 8 different files.  So if you use "sed" to change them all to
__CYGWIN_OFF_ (or something else harmless) and then do "./configure; make",
does it work?   (I don't have cygwin installed so this is not something I
can easily test.)

If it does work, then I move for the immediate banishment of all __CYGWIN__
macros.

If it doesn't work, is that a bug in cygwin?

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

On Thu, Jul 25, 2013 at 07:44:16AM -0400, Martin Gagnon wrote:
> Le 2013-07-25 06:43, Jan Nijtmans a écrit :
> >2013/7/25 Richard Hipp  :
> >> Native, pure-blooded windows binaries run just fine on cygwin,
> right?  So
> >> why are we complicating the code with exceptions, special cases,
> and hacks
> >> for cygwin?
> >
> > There are three things that a windows fossil binary can never do
> > in the Cygwin environment:
> > 1) handle Cygwin (Unix) links and mount points
> > 2) setting the Windows file-system case-sensitive (use both "Makefile"
> > and "makefile")
> > 3) use a Cygwin program as commit/stash editor
> >
> > For me personally those 3 things are not important, but apparently
> > (see earlier messages in this thread) for other people it is.
> Unfortunately!
> >
> > I'm trying to find out what the minimum patch is to get the Cygwin build
> > of fossil (both 32-bit and 64-bit) working again, so fossil can be
> > built out-of-the box on Cygwin again. Of course, any feedback
> > is welcome.
> 
> In Theory, fossil should build and work on fossil like on any other unix
> like Operating system (like linux/*bsd etc..) That's what cygwin is for.
> 
> I have the feeling that in some part of the code, cygwin is treated as
> windows and in other place it is treated as unix-like (posix). I guess
> this is the problem.
> 
> I believe that when building for cygwin, it should never goes on any
> #ifdef that are special for windows. So if cygwin really work as
> expected, fossil/sqlite code should not need much exceptions in order to
> work in Cygwin.
> 
> Per example, on native windows we cannot just do "./configure && make",
> we need a special manually maintain Makefile. But on cygwin, it *should*
> work.

This is also my understanding.

And as for "why we need fossil-for-cygwin" from Richard... I think it is almost
the same reason of why we need cygwin. :)

I don't use windows because I like it's UI. When I use windows, I want it the
closest to unix. This means terminals, fds, unix sockets, fork, process groups,
etc. Cygwin is great at building all that over the weird windows OS.

Using a non-cygwin program in cygwin quite breaks the magic (terminal fds not
passing on fork, different filesystem views, paths, permissions, etc.).

Regards,
Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Martin Gagnon]

Le 2013-07-25 06:43, Jan Nijtmans a écrit :

2013/7/25 Richard Hipp  :
>> Native, pure-blooded windows binaries run just fine on cygwin, 
right?  So
>> why are we complicating the code with exceptions, special cases, and 
hacks

>> for cygwin?
>
> There are three things that a windows fossil binary can never do
> in the Cygwin environment:
> 1) handle Cygwin (Unix) links and mount points
> 2) setting the Windows file-system case-sensitive (use both "Makefile"
> and "makefile")
> 3) use a Cygwin program as commit/stash editor
>
> For me personally those 3 things are not important, but apparently
> (see earlier messages in this thread) for other people it is. 
Unfortunately!

>
> I'm trying to find out what the minimum patch is to get the Cygwin build
> of fossil (both 32-bit and 64-bit) working again, so fossil can be
> built out-of-the box on Cygwin again. Of course, any feedback
> is welcome.

In Theory, fossil should build and work on fossil like on any other unix
like Operating system (like linux/*bsd etc..) That's what cygwin is for.

I have the feeling that in some part of the code, cygwin is treated as
windows and in other place it is treated as unix-like (posix). I guess
this is the problem.

I believe that when building for cygwin, it should never goes on any
#ifdef that are special for windows. So if cygwin really work as
expected, fossil/sqlite code should not need much exceptions in order to
work in Cygwin.

Per example, on native windows we cannot just do "./configure && make",
we need a special manually maintain Makefile. But on cygwin, it *should*
work.

May be I'm a bit naive ?


--
Martin G.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Jan Nijtmans]

2013/7/25 Richard Hipp :
> Native, pure-blooded windows binaries run just fine on cygwin, right?  So
> why are we complicating the code with exceptions, special cases, and hacks
> for cygwin?

There are three things that a windows fossil binary can never do
in the Cygwin environment:
1) handle Cygwin (Unix) links and mount points
2) setting the Windows file-system case-sensitive (use both "Makefile"
and "makefile")
3) use a Cygwin program as commit/stash editor

For me personally those 3 things are not important, but apparently
(see earlier messages in this thread) for other people it is. Unfortunately!

I'm trying to find out what the minimum patch is to get the Cygwin build
of fossil (both 32-bit and 64-bit) working again, so fossil can be
built out-of-the box on Cygwin again. Of course, any feedback
is welcome.

Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Richard Hipp]

Native, pure-blooded windows binaries run just fine on cygwin, right?  So
why are we complicating the code with exceptions, special cases, and hacks
for cygwin?

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Jan Nijtmans]

2013/7/24 Warren Young :
> The bundled SQLite is almost certainly broken with that patch because it
> probably isn't using the Cygwin 1.7.20+ F_LCK_MANDATORY feature, so it won't
> cooperate properly with any program based on native Windows SQLite.
Agreed. It was just an experiment. Closed now.

> I've already indicated that I'm going to wait until 3.7.18 comes out to see
> if they've fixed the backslash problem, and if they haven't, hack around it
> in Cygwin SQLite.  That still requires you to build Fossil with the system
> SQLite to get my fixes.

Next SQLite will be 3.8.0, which is in beta now, is already included in
Fossil. This means that the backslash problem is not fixed yet.

However, I think I found the cause of this problem! In os_win.c, the
function used to determine the temporary directory is
GetTempPath(). This function is documented to return:
1) The path specified by the TMP environment variable.
2) The path specified by the TEMP environment variable.
3) The path specified by the USERPROFILE environment variable.
4) The Windows directory.
We see that it apparently returns the Windows directory, it cannot
fiund any of the environment variables!
SQLITE_CANTOPEN: os_win.c:34887: (5)
winOpen(C:\Windows\etilqs_S8FDopj6QWC9mu4) - Access is denied.
$ ls -la /cygdrive/c
total 7265374
..
drwxrwx---+ 1 TrustedInstaller TrustedInstaller  0 May 23
09:10 Windows
..
We don't have sufficient rights in the C:\Windows directory! Cygwin clears
the Windows environment space, therefore none of the environment
variables can be found.

Proposed solution here (should move to sqlite if accepted):
   

Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Warren Young]

On 7/24/2013 05:30, Jan Nijtmans wrote:


It looks like SQLite is doing something wrong here:
  


That patch is fine on Cygwin as long as you build Fossil with the 
external SQLite, rather than the bundled SQLite.


The bundled SQLite is almost certainly broken with that patch because it 
probably isn't using the Cygwin 1.7.20+ F_LCK_MANDATORY feature, so it 
won't cooperate properly with any program based on native Windows SQLite.


(And if stock Fossil does turn on mandatory locking on Cygwin via the 
new Cygwin feature, they also need to add a way to turn it *off*, as 
Cygwin SQLite does with CYGWIN_SQLITE_LOCKING=posix, else the program 
won't be able to cooperate with other programs based on Cygwin SQLite.)



Could you try that fix, please?


What exactly are you asking me to do here?

I've already indicated that I'm going to wait until 3.7.18 comes out to 
see if they've fixed the backslash problem, and if they haven't, hack 
around it in Cygwin SQLite.  That still requires you to build Fossil 
with the system SQLite to get my fixes.


I don't have checkin rights on either Fossil or SQLite core, so if you 
want the stock distributed version changed in some way, you're better 
off asking one of the core developers.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

On Wed, Jul 24, 2013 at 08:01:47AM -0400, Martin Gagnon wrote:
> Le 24 juil. 2013 06:06, "Lluís Batlle i Rossell"  a
> écrit :
> >
> > On Wed, Jul 24, 2013 at 11:53:02AM +0200, Jan Nijtmans wrote:
> > > 2013/7/24 Lluís Batlle i Rossell :
> > > > I think our main usage for a cygwin fossil is that we develop using a
> cygwin
> > > > terminal with bash and vim. And we want fossil to spawn vim properly
> on commit.
> > >
> > > That should work, only you should do something like:
> > > export EDITOR="C:/Cygwin64/bin/bash.exe -c vim"
> > > I don't know vim enough to comment on that.
> >
> > Ah, the point isn't bash; the point is at processes passing properly the
> fds
> > for the *terminal*. I guess that once you put a non-cygwin process in the
> family
> > tree, the children can't access the terminal ancestor properly.
> >
> 
> Have you try  gvim -f ? (Native windows GUI version of vim) so your comment
> will not end by ':wq' :-)  like what could happens with notepad.

If I use windows with *all inside a cygwin terminal* is because I adapt very bad
to unusual environments. :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Martin Gagnon]

Le 24 juil. 2013 06:06, "Lluís Batlle i Rossell"  a
écrit :
>
> On Wed, Jul 24, 2013 at 11:53:02AM +0200, Jan Nijtmans wrote:
> > 2013/7/24 Lluís Batlle i Rossell :
> > > I think our main usage for a cygwin fossil is that we develop using a
cygwin
> > > terminal with bash and vim. And we want fossil to spawn vim properly
on commit.
> >
> > That should work, only you should do something like:
> > export EDITOR="C:/Cygwin64/bin/bash.exe -c vim"
> > I don't know vim enough to comment on that.
>
> Ah, the point isn't bash; the point is at processes passing properly the
fds
> for the *terminal*. I guess that once you put a non-cygwin process in the
family
> tree, the children can't access the terminal ancestor properly.
>

Have you try  gvim -f ? (Native windows GUI version of vim) so your comment
will not end by ':wq' :-)  like what could happens with notepad.

-- 
Martin G.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Jan Nijtmans]

2013/7/24 Warren Young 

>
> Just wait on the Cygwin64 people to bring out a new Sqlite package with
>> the same fixes already done in Cygwin32.
>>
>
> Um, it's the same people.  Me. :)
>
> Both packages are generated from the same source, with the same build
> options.  If they behave differently, it's likely because the SQLite code
> is doing something wrong with an ifdef, or because Cygwin itself behaves
> differently.
>
>
It looks like SQLite is doing something wrong here:
 
Of course, it was done for a good reason (cooperation
between Windows and Cygwin using the same sqlite
database), but now that that's fixed in Cygwin I think
that SQLite should be more UNIX-like on Cygwin.

Could you try that fix, please?

Regards,
   Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Warren Young]

On 7/24/2013 02:33, Jan Nijtmans wrote:

 SQLITE_CANTOPEN: os_win.c:34063: (3)
winOpen(/var/tmp/etilqs_FoaHNBQa56cVGrh\etilqs_PXfZEjH5dBl8Cm5) - The
system cannot find the path specified.


I'm not sure whether this is a SQLite 3.7.17 thing or if it is due to 
one of the build option changes in recent versions of Cygwin SQLite. 
All I know is that it seems to be a new thing.


As you can see from the error, SQLite is generating a temp file name 
with backslashes in it.  This is purely wrong on Windows, whether 
running under Cygwin or not.


I haven't bothered looking any deeper into it than that.  I hope it just 
gets fixed for me in .18.  If not, I may have to hack around it in my 
next release of Cygwin SQLite.


In the meantime, some people have had luck setting the new environment 
variable CYGWIN_SQLITE_LOCKING=posix.  This means Cygwin SQLite won't 
interoperate well with Windows native SQLite, but if you don't need 
that, I believe it will bypass this problematic tmp file name generation.



Just wait on the Cygwin64 people to bring out a new Sqlite package with
the same fixes already done in Cygwin32.


Um, it's the same people.  Me. :)

Both packages are generated from the same source, with the same build 
options.  If they behave differently, it's likely because the SQLite 
code is doing something wrong with an ifdef, or because Cygwin itself 
behaves differently.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

On Wed, Jul 24, 2013 at 11:53:02AM +0200, Jan Nijtmans wrote:
> 2013/7/24 Lluís Batlle i Rossell :
> > I think our main usage for a cygwin fossil is that we develop using a cygwin
> > terminal with bash and vim. And we want fossil to spawn vim properly on 
> > commit.
> 
> That should work, only you should do something like:
> export EDITOR="C:/Cygwin64/bin/bash.exe -c vim"
> I don't know vim enough to comment on that.

Ah, the point isn't bash; the point is at processes passing properly the fds
for the *terminal*. I guess that once you put a non-cygwin process in the family
tree, the children can't access the terminal ancestor properly.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

On Wed, Jul 24, 2013 at 11:53:02AM +0200, Jan Nijtmans wrote:
> 2013/7/24 Lluís Batlle i Rossell :
> > I think our main usage for a cygwin fossil is that we develop using a cygwin
> > terminal with bash and vim. And we want fossil to spawn vim properly on 
> > commit.
> 
> That should work, only you should do something like:
> export EDITOR="C:/Cygwin64/bin/bash.exe -c vim"
> I don't know vim enough to comment on that.
> 
> Windows Fossil nowadays uses Notepad.exe as default
> commit editor, isn't that much easier?

notepad easier than vim? Not at all, for a brain trained on vim. :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Jan Nijtmans]

2013/7/24 Lluís Batlle i Rossell :
> I think our main usage for a cygwin fossil is that we develop using a cygwin
> terminal with bash and vim. And we want fossil to spawn vim properly on 
> commit.

That should work, only you should do something like:
export EDITOR="C:/Cygwin64/bin/bash.exe -c vim"
I don't know vim enough to comment on that.

Windows Fossil nowadays uses Notepad.exe as default
commit editor, isn't that much easier?

Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

On Wed, Jul 24, 2013 at 11:16:19AM +0200, Jan Nijtmans wrote:
> 2013/7/24 Lluís Batlle i Rossell :
> > Do you happen to know if I can build and run programs for cygwin32, in a
> > cygwin64 installation? or I should run two cygwin setups in orthogonally, 
> > 32 and
> > 64?
> 
> I would recommend to compile fossil using:
> make -f win/Makefile.mingw PREFIX=x86_64-w64-mingw32-
> Then you get a WIN64 version of fossil.exe which
> works in any environment (Cygwin32, Cygwin64, Msys, CMD),
> and is super fast.

I think our main usage for a cygwin fossil is that we develop using a cygwin
terminal with bash and vim. And we want fossil to spawn vim properly on commit.

iiuc, a native fossil can't spawn a proper vim editor in the cygwin bash
terminal. Is it right? Do you know any workaround?

> All Cygwin64 and Cygwin32 dll's have the same name, so you
> cannot mix executables from those two environments.

Ah ok. Good to know!

Thank you,
Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Jan Nijtmans]

2013/7/24 Lluís Batlle i Rossell :
> Do you happen to know if I can build and run programs for cygwin32, in a
> cygwin64 installation? or I should run two cygwin setups in orthogonally, 32 
> and
> 64?

I would recommend to compile fossil using:
make -f win/Makefile.mingw PREFIX=x86_64-w64-mingw32-
Then you get a WIN64 version of fossil.exe which
works in any environment (Cygwin32, Cygwin64, Msys, CMD),
and is super fast.

All Cygwin64 and Cygwin32 dll's have the same name, so you
cannot mix executables from those two environments.

Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

Great! Very informative. Thank you.

Do you happen to know if I can build and run programs for cygwin32, in a
cygwin64 installation? or I should run two cygwin setups in orthogonally, 32 and
64?

On Wed, Jul 24, 2013 at 10:33:38AM +0200, Jan Nijtmans wrote:
> On Mon, Jul 22, 2013 at 09:21:57PM +0200, Lluís Batlle i Rossell wrote:
> > Hello,
> >
> > today I built fossil on cygwin64, and it built but "it didn't work". 
> > Cloning, a
> > line in os_win.c complained about not having permission to create a file (a 
> > tmp
> > file with some kind of random string) in C:/windows.
> I can easily reproduce that (see below). The Cygwin folks made some local
> modifications to sqlite, allowing cooperation between Cygwin and Windows
> programs. Cygwin64 doesn't have those modifications yet.
> 
> 2013/7/22 Martin Gagnon :
> > I stop building fossil for cygwin long time ago and I found that cygwin
> > version of fossil was a lot slower (with big repo) and I had problem
> > when using the same checkout from cygwin and non-cygwin binary.
> 
> That should be fixed now. For details, see:
> 
> 
> You can try it on Cygwin32 using
> ./configure --disable-internal-sqlite
> There it should work fine now, but feel free to report any additional
> problems you find.
> 
> On Cygwin64 that doesn't work yet due to the above mentioned reason:
> $ ./configure --disable-internal-sqlite
> 
> $ make
> 
> $ ./fossil update
> Autosync:  
> SQLITE_CANTOPEN: os_win.c:34063: (3)
> winOpen(/var/tmp/etilqs_8td6VBhZb6xMX3V\etilqs_QL9aCIutNgLB3ZP) - The
> system cannot find the path specified.
> SQLITE_CANTOPEN: os_win.c:34063: (3)
> winOpen(/var/tmp/etilqs_FoaHNBQa56cVGrh\etilqs_PXfZEjH5dBl8Cm5) - The
> system cannot find the path specified.
> SQLITE_CANTOPEN: cannot open file at line 34071 of [cbea02d938]
> SQLITE_CANTOPEN: statement aborts at 38: [CREATE TEMP TABLE
> onremote(rid INTEGER PRIMARY KEY);] unable to open database file
> ./fossil: unable to open database file: {CREATE TEMP TABLE
> onremote(rid INTEGER PRIMARY KEY);}
> 
> If you have recently updated your fossil executable, you might
> need to run "fossil all rebuild" to bring the repository
> schemas up to date.
> 
> Just wait on the Cygwin64 people to bring out a new Sqlite package with
> the same fixes already done in Cygwin32.
> 
> Thanks!
> 
> Regards,
>Jan Nijtmans
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Jan Nijtmans]

On Mon, Jul 22, 2013 at 09:21:57PM +0200, Lluís Batlle i Rossell wrote:
> Hello,
>
> today I built fossil on cygwin64, and it built but "it didn't work". Cloning, 
> a
> line in os_win.c complained about not having permission to create a file (a 
> tmp
> file with some kind of random string) in C:/windows.
I can easily reproduce that (see below). The Cygwin folks made some local
modifications to sqlite, allowing cooperation between Cygwin and Windows
programs. Cygwin64 doesn't have those modifications yet.

2013/7/22 Martin Gagnon :
> I stop building fossil for cygwin long time ago and I found that cygwin
> version of fossil was a lot slower (with big repo) and I had problem
> when using the same checkout from cygwin and non-cygwin binary.

That should be fixed now. For details, see:


You can try it on Cygwin32 using
./configure --disable-internal-sqlite
There it should work fine now, but feel free to report any additional
problems you find.

On Cygwin64 that doesn't work yet due to the above mentioned reason:
$ ./configure --disable-internal-sqlite

$ make

$ ./fossil update
Autosync:  
SQLITE_CANTOPEN: os_win.c:34063: (3)
winOpen(/var/tmp/etilqs_8td6VBhZb6xMX3V\etilqs_QL9aCIutNgLB3ZP) - The
system cannot find the path specified.
SQLITE_CANTOPEN: os_win.c:34063: (3)
winOpen(/var/tmp/etilqs_FoaHNBQa56cVGrh\etilqs_PXfZEjH5dBl8Cm5) - The
system cannot find the path specified.
SQLITE_CANTOPEN: cannot open file at line 34071 of [cbea02d938]
SQLITE_CANTOPEN: statement aborts at 38: [CREATE TEMP TABLE
onremote(rid INTEGER PRIMARY KEY);] unable to open database file
./fossil: unable to open database file: {CREATE TEMP TABLE
onremote(rid INTEGER PRIMARY KEY);}

If you have recently updated your fossil executable, you might
need to run "fossil all rebuild" to bring the repository
schemas up to date.

Just wait on the Cygwin64 people to bring out a new Sqlite package with
the same fixes already done in Cygwin32.

Thanks!

Regards,
   Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Martin Gagnon]

On Mon, Jul 22, 2013 at 09:21:57PM +0200, Lluís Batlle i Rossell wrote:
> Hello,
> 
> today I built fossil on cygwin64, and it built but "it didn't work". Cloning, 
> a
> line in os_win.c complained about not having permission to create a file (a 
> tmp
> file with some kind of random string) in C:/windows.
> 
> I wonder... why is it running any os_win code? shouldn't cygwin look like 
> unix, to
> fossil?
> 
> I've been using happily fossil in cygwin 32-bit since years, and only today I
> tried this cygwin64 (completely new for me). Has anyone tried it? Maybe I am
> doing something very wrong.
> 
> I tried both the 'configure' makefile, and Makefile.classic.

I don't know if it can help you,  but I use mingw64 with bash shell from
msys and I don't have this problem. MinGW version should use a bit more
more from the os_win code since it's not emulating a fully posix
environement like cygwin.

I stop building fossil for cygwin long time ago and I found that cygwin
version of fossil was a lot slower (with big repo) and I had problem
when using the same checkout from cygwin and non-cygwin binary.

-- 
Martin G.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Stephan Beal]

On Mon, Jul 22, 2013 at 9:21 PM, Lluís Batlle i Rossell wrote:

> I've been using happily fossil in cygwin 32-bit since years, and only
> today I
> tried this cygwin64 (completely new for me). Has anyone tried it? Maybe I
> am
> doing something very wrong.
>

Speculation: i _suspect_ that the C macros which determine "is this
cygwin/mingw" simply misfire for 64-bit environments.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

Hello,

today I built fossil on cygwin64, and it built but "it didn't work". Cloning, a
line in os_win.c complained about not having permission to create a file (a tmp
file with some kind of random string) in C:/windows.

I wonder... why is it running any os_win code? shouldn't cygwin look like unix, 
to
fossil?

I've been using happily fossil in cygwin 32-bit since years, and only today I
tried this cygwin64 (completely new for me). Has anyone tried it? Maybe I am
doing something very wrong.

I tried both the 'configure' makefile, and Makefile.classic.

Regards,
Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users