<div dir="ltr">Hey guys,<div><br></div><div>I narrowed it!</div><div><br></div><div>It took me a little while to get the windows dev env in place, but instructions in <span style="font-size:12.8px">packaging/</span><span class="gmail-il" style="background-color:rgb(255,255,255);font-size:12.8px">windows</span><span style="font-size:12.8px">/mxe-based-</span><wbr style="font-size:12.8px"><span style="font-size:12.8px">build.sh were very helpful.</span></div><div><span style="font-size:12.8px">Only one little call to curl's buildconf script is missing in mxe-based-build.sh but once done manually the rest went smoothly. I may fix this in a separate commit, maybe together with automatically cloning dependencies from github...</span><br></div><div>It "only" took 8h to build mxe inside the vm, thanks to the warning in the comments and from Dirk's last message, I started the build before going to bed :)</div><div><br></div><div>Back to the non-ASCII user name/path for local checkout of the repository, the issue is caused by the call to stat(sys/stat.h) that do not support non-ASCII paths. I could not find a place that was stating it explicitly but seems reasonable explanation. Since the cloning and checkout itself works in libgit2 I made some digging in that code and there a set of portability functions are used (p_stat) with simple mapping to system's stat() for posix systems and specific implementations using win32 APIs for win case.</div><div><br></div><div>As a proof of concept I added an ugly: "extern int p_stat(const char* path, struct stat* buf);" on top of git-access.c and used it in get_remote_repo and is_git_repository (these are the 2 only places stat function is used in the whole project). It fixed my issue (I could Open and Save could storage)...</div><div><br></div><div>Now what should we take as a fix:</div><div>1. The ugly extern</div><div>Cons</div><div>I call it ugly since (in libgit2) that function is not actually exposed in the headers, not sure how Android and iOS apps are built (actually linked...) so it could caused some issues there.</div><div>I have to mention the "bad design" / hidden dependency to libgit2 internals argument too.</div><div><br></div><div>Pros</div><div>On the other hand it is quite an easy fix for the time we do not encounter other compatibility issues in other places of the soft.</div><div>It is (currently) limited to <b>git</b>-access.c so (if it does not raise issues on other platforms/targets) having a tight coupling to libgit2 internals could be acceptable.</div><div><br></div><div>2. Implement our own portable is_dir</div><div>In all the places stat function is used, it is to check if the path is a directory (and exists). Going through a portable stat is a bit "overkill" (processing to provide all the elements that output "struct stat" needs) when we only need to know if we have a directory. Not that this part of the code is actually perf critical, it is always good to ask ourselves the question.</div><div>Plus it makes the code a bit more readable. I think this option is my favorite and would avoid issues in other platforms (if they exist at all).</div><div><br></div><div>3. Implement our own portable stat</div><div>The choice between this option and the previous is_dir proposal is always hard when it comes to portability (specifically with windows).</div><div>Should you port system calls or should you write client code using higher level abstractions is always a big debate.</div><div>Furthermore, in bigger projects that use multiple 3rd party libs the portage is often already done in several of the included libs, so writing yet another port results in adding code that typically already exists multiple times in your final binary...</div><div>I'm more often working with C++ so I tend to love abstractions, when it comes to C the choice is a bit harder.</div><div>Subsurface core is, from my point of view, higher level code so I would go for abstraction, but I'm curious to hear about other point of views.</div><div><br></div><div>3. Other proposal?</div><div>There could be other solutions I have overseen, do you guys think about something else?</div><div><br></div><div><br></div><div>I'm still a bit fresh with this project and do not have yet an overview of all use cases, platforms and targets that are involved, this is why I preferred to ask before proposing a pull request with changes that could have side effects...</div><div>On a related point, I have not looked yet on how testing is done, (and how far it goes) I would be more than happy to extend the test with this use case, I'd only need a bit of guidance.</div><div><br></div><div>While we are talking about porting, is there a thread I could look into to understand the choice that was made to go for cross compilation rather than building on target? cmake is quite helpful in that regard. Maybe the main reason is that most developer do not want to install a win VM to check their code do build there :)</div><div><br></div><div>Cheers,</div><div><br></div><div>Jeremie</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-02-19 23:24 GMT+07:00 Dirk Hohndel <span dir="ltr"><<a href="mailto:dirk@hohndel.org" target="_blank">dirk@hohndel.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Feb 19, 2017 at 05:32:15PM +0700, Jérémie Guichard wrote:<br>
><br>
> Computer is Suunto Zoop. With Suunto DM5 I have to sync multiple times<br>
> before all logs are synced...<br>
<br>
</span>Yeah, DM5 is a very special piece of s... err... software.<br>
<span class=""><br>
> I'll take a look into translations, I normally use English interfaces, just<br>
> switched to french to see the status, seems pretty complete though some<br>
> translations could be improved. I guess I'm a bit late for the 4.6.2...<br>
> Website seems to be a bit more behind...<br>
<br>
</span>Yes, 4.6.2 will hopefully go out today.<br>
<br>
It's funny, I can't stand translated UIs, either, but our data tell us<br>
that more than half our users indeed use translated UIs...<br>
<span class=""><br>
> Indeed I used official 4.6.1 installer.<br>
><br>
> No specific ACLs on the directory. But my user name do contains the french<br>
> "é". So I created a new user with only ASCII chars, cloud storage features<br>
> Open/Save are working fine. You have found the issue, yepee!!!<br>
<br>
</span>Excellent. So we have a workaround.<br>
<span class=""><br>
> How should I proceed? ticket, fix, etc. I must admit I'm not there yet with<br>
> setting up dev env, I only got to build from source yesterday in the ubuntu<br>
> virtual machine... (btw I had a short attempt to do so using linux<br>
> subsystem for windows but did not succeed...)<br>
<br>
</span>Building under Windows is incredibly painful. Lubomir was the only person<br>
who every got it to work reliably, and I think even he ran into problems<br>
lately. There is a file packaging/windows/mxe-based-<wbr>build.sh that should<br>
allow you to cross build a Windows installer under Linux. Read the file<br>
for some of the setup you need to do to make this work. Even on a fast<br>
system, the first run through takes quite a while - but it gets better<br>
once all the libraries are built.<br>
<br>
I would love to see another developer with Windows background (and an<br>
interest in Windows as their main platform) start contributing. As it<br>
happens, almost all of the developers run Linux or Macs as their platform<br>
of choice, and Lubomir, our main Windows developer (without whom there<br>
really wouldn't be a functional Windows version) is actually not a diver<br>
and only does this for the love of programming...<br>
<span class="HOEnZb"><font color="#888888"><br>
/D<br>
</font></span></blockquote></div><br></div>