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. windows support is another big one. do we know the state on osx? > > > >> 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. 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. > Pretty sure there will be more, but the question is if we find out > before we drop autotools or not. > > regards > Stefan Schmidt > > > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
