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 (#358 (comment)):

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)

libui/.travis.yml

Line 1 in 9d74f9f

language: c

[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.