On Thu, Aug 7, 2008 at 7:43 AM, Xavier <shiningxc@gmail.com> wrote:
On Thu, Aug 7, 2008 at 2:17 PM, hoar heor <archye@pycut.com.ar> wrote:
I don't really understand what you mean with gettext, as far as I know it's using it(although I maybe had skipped something)
<snip>
I know i't's a bit complicated, but otherwise it would source the file several times if there are more arguments(maybe there's some other way simpler to do it that I haven't noticed, anyway I'm still looking at the source to simplify it)
I meant getopts of course...
well, it's not only intended to be used with "safe" makepkg, look it this way, someone has -arch and -mute changed to his platform so the packages are optimized, the problem is that they won't work on other processor, if that person builds the package for a repo he will have to change makepkg.conf in this way he could do makepkg --config=release and it would source makepkg.release(witch obviously must have had created earlier), or maybe a specific makepkg for one package makepkg --config=python wich would use makepkg.python
Obviously, the symlinks solution is not limited to two configs either.
And the env var way can be modified as well to support any configs. Just use MAKEPKGCONF="configname" Then makepkg.conf can be just one line : source /etc/${MAKEPKGCONF:-makepkg.conf.default}
Let's take a step back here. Problem: it is not easy to build packages with different makepkg.conf files. Seemingly simple solution: add a command-line parameter to specify a different config file. The original solution proposed was too restrictive IMO, we do crazy things with adding extensions to a hardcoded /etc/makpkg.* location and who knows what. We should at least give the option of picking a config file from any location. Besides that, we may need to revisit the fact that both /etc/makepkg.conf and ~/.makepkg.conf are currently read; is this really not sufficient for most needs? To be honest, makepkg is so rarely run as root and almost always run as a user that it makes more sense to only read the homedir file if we weren't trying to be backward compatible. But now I'm off on a tangent. :) What was wrong with moving the config file reading after the getopt options parsing? Did I miss something, or can't we handle a --config option in this same fashion? I agree we might have a valuable feature request here; I just think the first patch took the wrong approach and was too specific anyway. -Dan