Re: pkg/44695 (Please add build setting for multi-packages to _BUILD_DEFS [patch])

[Aleksey Cheusov <cheusov%tut.by@localhost>]

The following reply was made to PR pkg/44695; it has been noted by GNATS.

From: Aleksey Cheusov <cheusov%tut.by@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/44695 (Please add build setting for multi-packages to 
_BUILD_DEFS [patch])
Date: Sun, 13 Mar 2011 14:27:46 +0200

 > I've committed the patch, thank you.
 Thanks!
 
 > Shouldn't there be a MULTI setting for emacs also?
 My original intention was to specify only *_REQD and PKG_APACHE settings
 in MULTI because they are not controlled by mk.conf and packages built
 for different versions of e.g. python can coexist on the same system.
 On the one hand, if we follow "rebuild package easily with original
 settings" task, we should also add X11_TYPE and EMACS_TYPE to MULTI. On
 the other hand neither emacs packages nor X packages are true
 "multi-packages". Only one variant of them is built by official bulk
 builds and by users too. So, it is unlikely to see packages built for
 different flavours of emacs and native/modular X on single system.
 I have no strong opinion here but it seems to me it is safer to *not*
 add X11_TYPE and EMACS_TYPE, at least for now.
 
 As to EMACS_TYPE I think our emacses need to be improved. At the moment
 emacs modules have only one variant in official binary repository.
 Solution may be:
 1) Make GNU emacs and xemacs modules "multi-packages" by introducing
   EMACS_DEFAULT, EMACS_ACCEPTED and EMACS_REQD, for example,
   and then add EMACS_REQD to MULTI.
 2) Move installation of .el and generation of .elc files to INSTALL
   script, that is to move some tasks from package build time to
   installation time and to have only one binary package for all flavours
   of emacses just like Linuxes do.
 Personally, I think that variant 2 is much better, however this is a
 completely different question.
 
 And. What do you guys think about converting multi-packages to OPTIONS
 framework in a long run?
 
 -- 
 Best regards, Aleksey Cheusov.