I'd rather not start creating meta build systems that we then need to track and maintain. I will temporarily add a tarball for meson 0.39 until Debian decides to do an update for the package.
I further don't see any point in keeping an autogen.sh script when all it does is add an unnecessary extra step to the build process; with meson it's 2 steps: meson -Doptions=values . build cd build && sudo ninja install The reason for autogen.sh existing in the first place was because autoreconf used to be unreliable, so it was necessary to explicitly run commands in a certain order. An autotools example build: autoreconf -fi ./configure --options=values sudo make install As seen in the above examples, there is not much point in keeping the script. Packagers will update their packages accordingly and power users who run off git will need to be using meson/ninja anyway. On Mon, Nov 6, 2017 at 8:10 AM <marcel-hollerb...@t-online.de> wrote: > On Mon, Nov 06, 2017 at 11:33:26AM +0100, Stefan Schmidt wrote: > > Hello. > > > > On 11/06/2017 11:00 AM, Simon Lees wrote: > > > > > > > > > On 06/11/17 20:19, Stefan Schmidt wrote: > > >> Hello. > > >> > > >> On 11/03/2017 07:07 PM, Mike Blumenkrantz wrote: > > >>> The E22 release is out now, so it's time to return to this issue. > Currently > > >>> we have two build systems, and maintaining/updating both of them is > not > > >>> feasible. At present, there is already significant divergence and > various > > >>> features are not present in the autotools build (and never will be). > The > > >>> decision is not whether to remove autotools or when to remove > autotools, > > >>> it's what do we do about old distros. > > >> > > >> Do we know which old distros are having this problem? > > >> This is a very similar to other external deps we have. We never > really set rules on what version our dependencies can have based on what > > >> distros are shipping. We simply handled them when issues came up. > > >> > > >> If the distros are not the latest release of the very distro I would > argue that they should upgrade. LTS versions are tricky though. > > >> > > >>> Based on previous discussions, it seems that there are still some > users > > >>> whose distros do not yet ship a modern enough version of meson. The > best > > >>> option, which is the option other projects which switch to meson > have been > > >>> using, is to simply ship a tarball of a newer meson release along > with our > > >>> code. The other option is to provide a link in the README. I don't > have any > > >>> other ideas. > > >>> > > >>> I'll be removing autotools sometime next week, let's try to get some > > >>> discussion going about the best action to take going forward with > this. > > >> > > >> I would suggest the following: > > >> 0) Dig a bit around to see what distros have a *latest* release which > does not ship 0.39 > > >> 1) Add a small a link and comment into the README > > >> 2a) If the majority of distros have it already simply go with the > README solution > > >> 2b) If the majority of distros miss the needed meson version either > ship the tarball or use the autogen.sh pr-build download script Raster > > >> suggested > > >> 3) Remove autotools support and monitor what problems come up to > point people in the right direction > > >> > > >> regards > > >> Stefan Schmidt > > >> > > > From a brief memory of when I checked I think Debian was the main one > > > and given they released earlier this year they are still a year or two > > > off having a new version unless it can be added in some form of > > > backports etc. > > > > That is a pity. If it is only Debian though I wonder if we should put > the burden of shipping and updating meson our-self. > > My hope would be that the amount of other software needed a new meson > now would bring in some sort of backport for Debian. > > > > In the end I do not want to see users out there standing in the rain. If > Mike is happy with having the meson tarball shipped with E or > > having a script that downloads it for the poor folks with and old > version that should be ok until Debian catches up. > > Things could even be simpler, (I dont know details, thats a idea from my > head right now, but i know that pip can install into a subdir). > > We could ship a script that can be used to build e with a custom meson. > So you could do something like: > > mkdir build && cd build > python ../meson_custom .. > > The script then just downloads meson using pip into a subdirectory, and > uses that downloaded meson for executing the buildtool. So we only > really would require python on a build system. > > Greetings, > Marcel Hollerbach <bu5hm4n> > > > > > > regards > > Stefan Schmidt > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
