> That''s a good idea--you suggest to core that they implement some
type
> of checking that reports back when the build breaks [or at least when
> tests break].
>
> If it reported all tests that break on mingw with each commit,
> why...nobody would ever want to commit again LOL.
>
> That really would be the perfect world, though--all the test-suite
> passes on every platform and breaking the build [even for windows] is
> considered a bad thing.
Yeh, it is a funny situation on many levels isn''t it? ;)
While I''m not aiming for Build Nirvana For All Time, I am interested in
finding ways to incrementally raise the visibility level of building from source
on Windows systems, and specifically how it relates to rubyinstaller as the
distribution platform.
I''m remembering a rash of posts on ruby core in March from Charlie
Savage trying to build using cl.
That said, none of these rambling should distract from pushing rubyinstaller out
as quickly as makes sense, right?
To have any chance of being useful I think you''d have to make multiple
"build levels" so people could pay attention only to what
they''re interested in. For example, if you''re a core
committer and you are only mildly interested to see how the latest source is
building with MinGW.
At least the following:
1) Core Stable - does the latest committed Ruby source build stable MinGW env
used by rubyinstaller and devkit (e.g. - 3.4.5). Goal is to make code induced
build errors as early as possible in an automated fashion.
2) Core Twitchy - same as (1) except using "next" version of MinGW
(e.g. - 4.4.0)
3) RubyInstaller Stable - similar to (1) but also adds in all the dependencies
created by using rubyinstaller''s recipes, etc. Goal is to quickly see
if you can build using the full rubyinstaller environment. Ruby core folks
would likely care less about this and the next level.
4) RubyInstaller Full - (3) with a check that the installer actually builds.
...and I can "subscribe" to whatever level I care to see...
Jon