[Debian GNUstep maintainers] Extending config.mk

[Gürkan Myczko]

I think I already migrated my gnustep debian packages. It works quite well.

About oolite it would be great to keep but I probably can’t maintain that parts you mentioned.

What about the stuff in github nextspace? It seems to only build with libobjc 2...?

Meanhwile we have chess.app, pikopixel.app, and fontmanager.app...

Regards,

Gürkan

> On Dec 19, 2017, at 00:00, Yavor Doganov <yavor at gnu.org> wrote:
> 
> These days it seems fashionable to minimize debian/rules as possible,
> so I suggest to add
> 
> messages := yes
> 
> to gnustep-make/debian/addons/config.mk.
> 
> That way, each package can stop defining it explicitly if it simply
> includes config.mk.  The only problem I see with this change is that
> we'll get verbose output for all other targets like install/distclean
> and we generally don't need that.  (I used to define messages=yes
> during install for a specific package long time ago when I was chasing
> an obscure gnustep-make bug.  It turned out to be a bug in the
> makefile; upstream was using a private variable that was either
> removed or changed semantics in a new gnustep-make release.)
> 
> IMHO a better approach would be to define in config.mk:
> 
> gnustep_build_cmd := dh_auto_build -- $(optim) messages=yes \
>                 $(shell dpkg-buildflags --export=cmdline)
> 
> For most packages, it would be sufficient to do:
> 
> override_dh_autobuild:
>    $(gnustep_build_cmd)
> 
> We can drop the override entirely if GNUstep Make is fixed to honor
> environment variables (on my TODO list, along with other enhancement
> proposals that I have to discuss on gnustep-dev@ first).
> 
> Hubert had the vision that maintaining a GNUstep package shouldn't be
> any different or harder than any other package, and that all
> GNUstep-specific things should be wrapped in Debian-specific tool and
> machinery that should work out of the box.  This was the idea of
> gsdh_gnustep and the cdbs implementation, although gsdh_gnustep was
> never finished.  CDBS works without major changes after all these
> years, which is amazing.  (JFTR, I dislike CDBS very much but decided
> not to migrate some packages to dh in order to test the GNUstep cdbs
> stuff.)
> 
> When debhelper evolved to dh, initially I thought that we should
> implement a specific "gnustep" debhelper buildsystem.  I no longer
> share this opinion, because GNUstep packages need very few additional
> things on top of the standard debhelper buildsystem and we should
> attempt to implement them via config.mk.
> 
> I think we should kill gsdh_gnustep entirely, starting with the
> horrible hack gs_make first.  Since the "debian" layout was added in
> gnustep-make, the only *useful* job that gsdh_gnustep was doing was
> for the core GNUstep packages.  But Eric changed them to use standard
> dh files/tools and eliminated the ${gnustep:Depends} substvar.  I
> think the core packages are more complex now, but that's just my
> opinion and I fully agree that the added complexity of two packages is
> worth it if we can get rid of the gs_* things.
> 
> WDYT?
> 
> 
> _______________________________________________
> Debian GNUstep maintainers mailing list
> pkg-GNUstep-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gnustep-maintainers
>