Re: IOS and gbuild

Hi,

On Fri, Jun 23, 2017 at 02:32:21PM +0200, Jan Iversen wrote:
> 1) how to make “make build-nocheck” default as “make”
> This is more a convenience, but IOS is linked without the possibility of running many of the test 
> (due to the limited IOS sandbox environment)
>
> Can I somehow have a 
>
> ifeq ($(OS),IOS)
>    make build-nocheck
> endif

I really dont think we want the behavior of "make" to be platform-specific in
that way. There is already way too much special casing and the ESC has
historically been very clear that "make build-nocheck" should not be used used
by anyone except e.g. release engineers in their build scripting when they
explicitly run the tests independantly later.

Failing tests should never be the default on a platform -- as such please
consider, if it is really only for convenience an local shell alias on your
machine, e.g.:

> alias make='make build-nocheck'

(Note that might break for use of make with args, if you care for that too
consider a more fancy function in your bashrc).

However, if your goal is to incrementally get a IOS platform up, propably the
way to go is to temporarily disable the failing tests, but keep those already
succeeding running. For that see e.g. how in vcl/Module_vcl.mk the
Cppunittest_vcl_timer test gets enabled on Windows only. Still, any failing
tests should be transistional only.

 
> 2) I need to exclude some modules, that are not optional like e.g. codemaker
>
> What would be the correct way to do that ?
> (I have searched for a list of all modules to be build, but not found it)

see RepositoryModule_*.mk for that. Note though, there is currently nothing
platform-specific in those, and it is likely good to keep it that way: Rather
this should be done by making those modules noop targets on the platform, as
this is the way it has been done before, see e.g. bean/Module_bean.mk, which
currently does nothing on OSX or Android.

Another benefit of the latter is that it might prevent time-consuming
confusion: If a module is sneakily skipped in RepositoryModule_*.mk, someone
might still cd into the module, run the build, find it failing and chasing a
regression/bug without being aware that it never even worked in the firstplace,
which is suboptimal.

OTOH, cding into and building a module, finding it does nothing on a platform
might also raise an eyebrow at first, but a look at e.g. "git blame
Module_*.mk" or "git log Module_*.mk" should explain the situation quickly in
this case.

Best,

Bjoern