On Wed, Feb 26, 2014, Stefan Schmidt wrote:
> Hello.
>
> On Tue, 2014-02-25 at 23:10, Adrien Nader wrote:
> > I am the main dev behind http://win-builds.org which makes builds for,
> > well, Windows. Everything is cross-compiled from linux64. Windows is one
> > of the platforms that gets built and tested less often
>
> It should get build for every push to efl master. Jenkins takes care
> of that. It is correct though that it is broken more often than the
> other builds.
>
> > and we found
> > several issues in beta1 (you can see windows and cross-compilation fixes
> > in git soon after beta1).
>
> Thanks!
Most changes required were fairly simple and half the work was to throw
any issue at cedric and jpeg. :)
I'm a bit surprised the bot could build successfully though. I guess
that either some issues were not noticed, that there timing issues
and/or that some things would succeed if the system already had a
previous cross-build installed. Difficult to say but again, there
weren't that many things to change in the end.
> > While I am a developer, I do not intend to take a more active role in
> > the development of the EFLs. Using them, yes; working on them, there's
> > simply no time for that. This is one of the reasons I don't build and
> > test intermediate versions. Another reason is that for platforms that
> > get tested less, this would mean getting way too many errors.
>
>
> And here we have the problem. Nobody is willing to invest in having
> efl working well on mingw/windows. You did some patches which is more
> than other people do so thanks for that.
>
> Still, what I mostly hear is like "EFL needs to support windows
> because the app I write should work there". But the reality is that
> none of the active developers is using it or working on it behind the
> causual bug fix if jenkins complains about broken builds. The mingw
> automated build on jenkins is as what Cedric and I did to have at
> leats an idea if we break stuff for mingw on the compilation side. Its
> as far as I personally will go.
>
> I siad it before and I will say it it again to everyone who wants efl
> top support mingw/windows as a first class citizen:
>
> If you don't do the work nobody else does.
>
> It may sound harsh but I have done my share on keeping the mingw port
> build even if I have _zero_ interest in it.
It's already much better than some libraries. The rules could be as
simple as:
1- don't break the build
2- try not to rely on _approaches_ that are specific to either Linux or
GNU; functions specific to one of them should be mostly fine but
approaches (think "cgroups"), not
Is there a place which centralizes the expected features by platform?
Like if someone adds an #ifdef around some feature, is it mentioned
somewhere which isn't the code?
> > I tried 1.9 beta1 because Cedric asked me to do it and I had some free
> > time that day. With only one week between beta and the release, it is
> > difficult to test and it is highly likely that my time will already be
> > allocated for something else. This is without even accounting for other
> > changes like evolving packaging, dependency on luajit (mostly to
> > evaluate it), ...
>
> I would suggest startring with the alpha that would give you one more
> week. To late now for 1.9 anyway just saying.
I know Cedric had kept the mingw port at least working. Unfortunately,
earlier testing was hampered by lack of time and new dependencies mostly
(which were not showstoppers but required mind time for packaging).
I will try to track stuff more closely, I'm finally getting close to the
end of my backlog^W^Wone of my backlogs.
> > >From my packager perspective, more time between beta and final release
> > is better. From my developer perspective, I actually like it when other
> > devs get bored with the feeling they have nothing to do near the end of
> > a stabilization period.
>
> If they would get bored it would be good. What I see though is that
> people loose interest if the stabilization phase is to long and just
> start working on new developments. In the end these people are not
> working on bug fixes and thus a longer time brings nothing.
True, that can happen as well.
> > The main need is to be able to iterate several times with {build, test,
> > report issue/send patch, have it commited} and for that the 1.9 setup
> > has been quite short. I believe the two weeks will be much better.
>
> You really should start with the alpha which gives you three weeks
> during 1.10 if the schedule I proposed holds.
I hope I can do builds earlier. That requires me getting 1.4 (at least
beta) of win-builds out but I'm confident on that.
> > PS: I also hope that before 1.10 alpha, I will have finished a few
> > changes to win-builds to harass most of you into testing for Windows.
> > PS2: Wine works well enough.
>
> Good luck finding people for that. :)
One of the core ideas behind win-builds is to make it easy enough to
build for Windows that people have no excuse not to do it and at least
do basic checks.
Clearly, 1.3 isn't as easy as it could be but 1.4 will; only requiring
to rebuild binutils, gcc and mingw-w64 (depending on the machine, around
30 minutes of fully-automated build time; once). After that, all Windows
packages are usable.
That said, I'm not sure how I'll forge people to actively use it to
check the support. Probably with croissants, or blackmail. Or maybe that
I want to use EFLs for the win-builds GUI and that there are already
around 1k installations per month while it really only launched 2 months
ago and I haven't done much for communication so far.
--
Adrien Nader
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
