[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/44695 (Please add build setting for multi-packages to _BUILD_DEFS [patch])
The following reply was made to PR pkg/44695; it has been noted by GNATS.
From: Aleksey Cheusov <cheusov%tut.by@localhost>
Subject: Re: pkg/44695 (Please add build setting for multi-packages to
Date: Sun, 13 Mar 2011 14:27:46 +0200
> I've committed the patch, thank you.
> 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.
Main Index |
Thread Index |