@Stefan Schmidt I did a bit of digging one would need to package and setup a PPA to be able to support any and all versions of meason in this case in terms of supported releases. If you like I can try and learn how to package and get something going in terms of a PPA for meason and hell maybe even a PPA for enlightenment.
-----Original Message----- From: Stefan Schmidt <ste...@datenfreihafen.org> Sent: 25 April 2019 09:43 To: Carsten Haitzler (The Rasterman) <ras...@rasterman.com>; Enlightenment developer list <enlightenment-devel@lists.sourceforge.net> Subject: Re: [E-devel] EFL Autotools freeze proposal 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 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
