Hello. On 24.04.19 23:23, Carsten Haitzler (The Rasterman) wrote: > On Wed, 24 Apr 2019 10:27:26 +0200 Stefan Schmidt <ste...@datenfreihafen.org> > said: > >> Hello. >> >> On 17.04.19 15:15, Carsten Haitzler (The Rasterman) wrote: >>> On Wed, 17 Apr 2019 08:19:35 -0400 Mike Blumenkrantz >>> <michael.blumenkra...@gmail.com> said: >>> >>>> Hi, >>>> >>>> We are currently in the 1.23 release cycle, and it seems agreed upon that >>>> we are planning to remove autotools prior to the 1.23 release. Overall, the >>>> meson build is in reasonable shape--there are some small issues on our main >>>> platforms (and larger ones for Windows)--and it should not be an issue to >>>> meet this goal. >>> >>> i thought meson was in better shape... >>> >>>> With this in mind, I would like to propose a freeze on the autotools build >>>> starting Friday. This means that we no longer modify the autotools build in >>>> any way in the master branch (excepting outstanding patches in phab), and >>>> instead focus entirely on ensuring the quality of the meson build system. >>> >>> i think we should push this off a few more weeks/month or 2. >> >> I would like to get reports on what is actually missing or problematic. >> We can push back the freeze a bit, but its only a freeze, not the >> autotools removal. And we need people to switch over to see if all the >> crazy use cases we do not have are covered. > > the issue i saw got fixed by bu5hm4n since, but we really need to go over > everything in detail before removing autofoo - ensure it matches up correctly > and installs the same things in the same places before removal.
One test that should shed some light one things is to build and install efl with autotools as well as meson and compare the two destirs to find differences in the install. windows support > is another big one. do we know the state on osx? OSX is building with meson for a long time on CI for every push. >>> >>>> There is not much action which would need to be taken for this: >>>> * stop patching build files >>>> * disable CI jobs for autotools >>>> >>>> >>>> I think this would help to streamline build system development and reduce >>>> overhead for this release. >>> >>> i agree on this - but the autofoo needs to still work and be up to date >>> until the point where meson is equivalent - the windows work is one ware it >>> needs to catch up on for sure as well as some other niggles. get all of >>> these up to snuff and... yup. drop autotools. >> >> ok, so a concrete list of things that blocks autotools freeze and removal: >> >> 1) Windows port: ecore_win32 (gdi and ddraw engines) need to work, maybe >> more to come, feedback from Vincent needed. > > yup. > >> 2) Meson minumim version requirement: Need to check if there is a >> backport for Ubuntu LTS, maybe a list with meson versions on different >> distros? > > there has to be a line we draw. thing of this: RH support their distro for 10 > years. does that means we need to also rely on 10 year old build tools too > because that is what distro does? just because distros are conservative > doesn't > necessarily mean we have to also be. This is very similar to how we work with new dependencies or new version of deps. Aiming to support the *latest* LTS release from distros should be a goal, if possible. When the meson version was brought up as problem the last tiem I remember talking to Marcel to find out if that version is needed for performance improvements or if it has fixes that are needed to actually build efl with meson at all. IIRC it was the last one. Still waiting on Simotek about which version of Suse he wants to support. Also Ubuntu LTS needs digging if there is a backport. Right now I do not see this as a dramatic setback. We still have at least 4 months to go before the next release (new distros will ship or get updated). What we should avoid though is to update the meson version requirement. > now, that being said, it does present a problem. this problem will eventually > go away in time, so perhaps it means no efl upgrade on those distros unless > they also get a backported newer meson too. the pip solution also works in > many > cases but not so much for official packagers as they have to stick to tools > provided on the distro, but packages can be built in a users environment where > they used pip to get a newer meson, so it can be done. it just requires being > a > bit dirty. For developers and users building from git its most likely fine as they tend to have newer distros. If not pip will do the trick for them. The issue is really more about official packages and distros that ship efl to give them a sane upgrade path. regards Stefan Schmidt _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
