Master issue for remaining CI hiccups

[andlabs]

I still prefer a single combined archive containing both libui itself and examples, but that apparently will cause problems for libui-node, which needs to download archives (instead of shipping the binaries with the source code). What do other bindings do?

Is it possible to say "don't generate artifacts under condition X Y Z"? Because I don't need all build configurations in the CI to produce artifacts, only specific ones.

Are we sure ${version} will be the tag name, and not master or 1.0.whatever in the case of AppVeyor? I still need to figure out what 1.0.whatever should really be...

I'll also need to include the LICENSE with the artifacts.

The remaining TODOs in both YAML files are also to be solved.

[andlabs]

CC @parro-it @msink

[andlabs]

One other thing I forgot we need to look into: testing build reproducibility via CI. This part won't block unless it's super trivial.

[andlabs]

And another TODO for myself: add info about file sizes for the artifacts; may be relevant to the first question in this issue

And one more: see if we really need test in the artifacts; I forget if I included these in my manually-created archives so far...

(Also AppVeyor is very slow but apparently I need to pay if I want even two simultaneous builds in a single commit :| Unless I am wrong, or I need to make the individual builds parallel a la make -j5, but in that case I wouldn't know what parameters to use)

[andlabs]

OH YEAH WHILE I AM REMEMBERING STUFF the Travis file used to have specific language: settings, but that wasn't matrixified, so IDK what needs or needed to be changed there... (and I forgot to ask back during the PR; sorry!)

[msink]

Is it possible to say "don't generate artifacts under condition X Y Z"? Because I don't need all build configurations in the CI to produce artifacts, only specific ones.

It's possible, if we remove artifacts: section and add that conditional logic into after_build: section. See Pushing artifacts from scripts

But maybe better way is just remove shared msvc2015 ans shared msvc2017 from build matrix? This will speedup build a little.

[mischnic]

I still prefer a single combined archive containing both libui itself and examples, but that apparently will cause problems for libui-node, which needs to download archives (instead of shipping the binaries with the source code). What do other bindings do?

Fine for now, I guess (https://github.com/andlabs/libui/pull/358#issuecomment-389397940):

msink: It depends - as libui is currently alpha, I personally prefer to be on "bleeding edge" - releases are rare, and some bugfixes are critical.

parro-it: I completely agree. So I'll just continue to publish from my fork for now... We can discuss again when 1.0.0 will come 😁

[mischnic]

(Also AppVeyor is very slow but apparently I need to pay if I want even two simultaneous builds in a single commit :| Unless I am wrong, or I need to make the individual builds parallel a la make -j5, but in that case I wouldn't know what parameters to use)

For msbuild, there's a flag: https://msdn.microsoft.com/en-us/library/bb651793.aspx#Anchor_0 For mingw32-make the -j flag should work.

the Travis file used to have specific language: settings, but that wasn't matrixified

It's still there: (or I misunderstood something)

https://github.com/andlabs/libui/blob/9d74f9f930117cbc7f8ee3566380dc290328dbba/.travis.yml#L1

[msink]

For msbuild, there's a flag: https://msdn.microsoft.com/en-us/library/bb651793.aspx#Anchor_0

Strange, but msbuild /m:2 increased build time from 1:00 to 1:20

For mingw32-make the -j flag should work.

But this one works - mingw32-make -j 2 decreased time from 3:20 to 2:00 (and just mingw32-make -j failed with message out of memory allocating 65536 bytes)

Another option for AppVeyor speedup is Rolling builds - if this mode enabled, each new git push will cancel all current queued/running builds, and the new one will be queued. There is no option for this in .appveyor.yml, this mode can only be enabled in the settings UI of a project.

[parro-it]

Another option for AppVeyor speedup is Rolling builds - if this mode enabled, each new git push will cancel all current queued/running builds, and the new one will be queued. There is no option for this in .appveyor.yml, this mode can only be enabled in the settings UI of a project.

Oh really useful options!

[andlabs]

@mischnic I meant language settings that specifically named Objective-C and probably also C++ I forget

[andlabs]

In re AppVeyor msbuild with 2 jobs being slower than with 1:

GetProcessAffinityMask(GetCurrentProcess()):
    Process - 2
    System  - 2
GetProcessAffinityMask(real handle):
    Process - 2
    System  - 2
GetSystemInfo() processor count: 2
GetNativeSystemInfo() processor count: 2

This indicates that running with 2 or even 3 concurrent processes in make or msbuild shouldn't be slower, so hmmm... I'll try myself with 2 and 3 later and see what happens. (Something, IIRC jhbuild but I forget now, always set n+1 jobs in its make, which is where I got the practice from.)

I may also consider turning on Build Cache, if that's even available to a free account. (If only non-Enterprise paid accounts weren't limited to two (2) concurrent builds...)

[parro-it]

I don't think neither travis nor appveyor does reserve CPU time for each running instance (at least not in the free version) so maybe their system is under more heavy load when @msink did his tests with the flags?

[andlabs]

@mischnic, @msink so I figured it out: the /m: option to msbuild is for the number of projects built simultaneously; libui is one huge project that is the dependency of a bunch of smaller ones, so that option won't help. What we really want is the /MP option to cl; msbuild runs cl only once (or maybe a few times) per project, and it's that cl invocation that then decides how many parallel compiles to do with /MP.

I'm still running a /MP3 build, but I'm not sure if it performs much better than an /MP2 build. I will say that the cmake step itself with the VS2015 and VS2017 generators seems to be a lot slower than cmake with the VS2013 generator for some reason, so I might try using nmake makefiles instead for all VS builds tomorrow morning.

[msink]

I'm not sure it worth troubles... Maybe just leave single msvc/shared build, there will be 6*2=12 configs, build time 15-20 minutes. With rolling builds enabled - tolerable.

[msink]

@andlabs You also can ask appveyor support (by email) what can be done. Maybe even they can turn on parallel build for this repository, I hear it was done in the past for some well-known opensource projects. Maybe you too have enougth github-stars for this :)

[andlabs]

Does the AppVeyor environment include any of the following?

• wget
• curl
• GNU make not in msys or mingw
• jom

[msink]

• curl 7.55.1 in PATH
• C:\cygwin64\bin\make

[msink]

If you want to experiment, better connect via Remote Desktop

[mischnic]

Here is a list (might not be complete): https://www.appveyor.com/docs/build-environment/

[andlabs]

All right. Not sure if jom comes with Qt, so I'll try the curl option instead, or building GNU make from source outside of mingw or msys.

[msink]

AFAIK pure GNU make cannot work on Windows, outside of cygwin or msys2.

[andlabs]

Yes it can. Download the source code, enter a MSVC shell, and run the included build_w32.bat file.

Anyway this experiment didn't work because trying to shove all this configuration into YAML is a recipe for disaster; it includes various cmd.exe complexities that I'd rather just split into separate .bat files before trying again (unless there's a magic yaml mode that lets me forego indentation for a single entry in a list, or use tabs for indentation instead of spaces, and at least ensures each entry in the yaml file is run in the same cmd.exe instance). We'll see what I decide tonight.

[msink]

Again, is it worth troubles? :)

Anyway, nowadays fastest and cross-platform build tool is not make but ninja.

[andlabs]

So I don't forget:

• One thread: 37:07
• Two threads: 23:33
• Three threads: 23:37

[andlabs]

data point: https://github.com/LeoTindall/libui-rs/commit/859e178c9f9147e278041fc7a486f2a49c9a3e07

[simplexidev]

I still prefer a single combined archive containing both libui itself and examples, but that apparently will cause problems for libui-node, which needs to download archives (instead of shipping the binaries with the source code). What do other bindings do?

I ship the binaries with LibUISharp.

I'm not sure what the reasoning is (and I'm pretty late to the party), but I think it would be helpful to have artifacts on commits that aren't tagged as well. Possibly a version like 0.4.0-build-# where # increases for each build would work (this wouldn't apply to PRs or any other branch besides master, of course). This would make it a lot easier in between releases to test bindings without having to build each time there's a commit to libui:master, as well as the dependencies to build (CMake, etc).

[andlabs]

The problem with that is that I normally make frequent tiny commits, so per-commit isn't going to work nicely. Some other granularity would be needed for that... and where would the artifacts go?

[simplexidev]

I know appveyor will hold them with each of the build results, and store them there (with some settings in the yml file), but I don't know about travis.

And travis will do daily builds (or weekly), also. You could probably set appveyor to do that as well, I don't know about that either, though.

[simplexidev]

On the topic of artifacts and appveyor, heres the artifacts from the latest build:

https://ci.appveyor.com/project/andlabs/libui/build/job/x35tskq2v0kewnqn/artifacts

[simplexidev]

For travis, I can only see adding releases to github by adding a prerelease or draft. I didn't realize travis doesn't have hosting built-in for artifacts, but instead you must use a third-party.

[andlabs]

And AppVeyor will soon be trashing old artifacts as well...

[simplexidev]

Well isn't that just nice? I guess the only way would be daily builds or weekly builds with some sort of prerelease tag (i.e -build or -daily). That seems like it would lead to clutter, though.

[andlabs]

New plan: since I'm going to release Alpha 4 as libui stands now, we'll test that the CI works using it. If any of the files are bad, I'll use a manually-created upload for that file instead, and we'll mark that one as needs attention here.

AppVeyor being slow can be dealt with later.

[simplexidev]

Sounds good. Once this is done, I'll have my own CI set up to make and distribute libui libraries with LibUISharp.

[andlabs]

One more TODO: make sure binary distributions in Azure Pipelines works.

I'll need to turn the above list of TODOs into a proper check list.