Well, I don’t think it’s the build step that is the biggest problem here, it’s when the download starts which is the problem. We’re investigating.
@Mathias_Westerdahl Our developers used Windows Editor can barely create a build after we introduced the native extension used google protobuf. Now this issue is a show stopper to our project, please try to address it on high priority.
First, it already has highest priority. We plan to release a new server today, which should fix the timeout issue.
Now, what actual issue do you and your developers have? You mention “which make the build process is miserable for Chinese developers”, which I interpret as it is in fact working (albeit slowly). Am I correct in this?
Once each team member has built the executable, it is cached locally, so you don’t have to build it again. That is, unless the extension developer checks in new versions.
We are also working on making the build faster, but that’s still one or more sprints away.
Thanks for the support!
macOS Editor can work but the build process is very slow (about 10 minutes)
Windows Editor almost cannot create a successful build and also very slow (about 10 minutes for each try)
Yes, we would not build the extension again if we do not close the editor for now. But for Windows developers, it is hard to create a successful build for now ( I just tried 5 times, and take almost 1 hour to create a Windows build). And we have to repeat the process once the extension codes has changed.
There is no build step done in the editors, so there should be no difference between using the macOS editor or the Windows Editor. All the build steps are done on our cloud server.
“if we do not close the editor for now”
Yes, I just realized this is still an issue. I’ve pinged @mats.gisselson and @Erik_Angelin to make them aware of your situation.
We are on it on multiple fronts then
Sorry for the misleading. I mean create macOS build and Windows build. I got the same result when I used macOS editor to create Windows bundle.
Ah, understood. Yes, the build times fix is also underway.
Hi
Has the new server fixing the timeout issue be released? My Defold editor still keep opening, although It has update available.
The first fix failed unfortunately, but we’re working on a second fix right now, which we’ll try today.
Not sure what you mean?
I cannot click this, because It will restart the Defold editor and trigger a new build,which will cause build timeout.
Now, we’ve updated the server timeout, and so far we haven’t seen any new timeouts issues during the last hours.
Also, we’ve just fixed the issue where the editor wanted to rebuild the engine after restarting the editor.
You can get that fix if you press the “Update available” button, and are using the “editor-alpha” version (You can check in the About dialog)
I just tried two times in windows7 in vmware, and it still timeout.
Most unfortunate. Well, we’ll continue working on it!
Any progress? I spent more than 6 hours to create Windows build but still failed, the team members using Windows Editor is on hold now…
It is being worked on right now. Are you actively developing a native extension or do you have one as a dependency?
We have a few native extensions in the project. Most of the extensions are stable and no need to recompile, but we also might need to fix bugs or add new features to them some times.
Ok. While we work to fix/improve build speed from for instance China I’m also thinking that maybe there are workarounds. What if you have a local server that simply returns a pre-built windows engine with the extensions you need. The problem is ofcourse when you need to make a change to the extension though. .
It is great if we have a pre-built Windows engine – if this solution works for our extensions compiling and linking process!
Since you’re talking about workarounds here, it might be easier to just copy the internal build cache?
It’s located under /.internal/cache/engine-archives
Note that this cache is invalidated with each engine release (e.g. a new Defold SDK)