On 6 January 2014 09:26, Kalrish Bäakjen wrote:
> Note, however, that the model I propose wouldn't introduce many changes.
You say that, but you also say this:
> There are also directories in /usr/lib that should be renamed.
To me, that by itself implies 'many changes'. Forgive me if I
misunder
On 6 January 2014 03:57, Kalrish Bäakjen wrote:
> My goal was to make it generic. SCons and Waf support the "-j" option, but
> that is coincidental. MAKEFLAGS is for make; why tweak it to make it work
> with other build systems? And, if other build systems support some options
> (for debugging, fo
On Sun, 2014-01-05 at 15:42 -0600, David C. Rankin wrote:
> On 12/31/2013 12:51 AM, Sébastien Leblanc wrote:
> > I would advise against doing that, considering that there are at least a
> > handful of packages (can't name them) that have broken or otherwise
> > malfunctioning Makefiles when run in
I think that it would be completely up to the Arch developers and to each
user. If there's only one application that depends on an outdated version
of a library, that application should be patched to work with the newer
version. If it's a very big program (say, X), however, or if there are lots
of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/03/2014 09:26 AM, Thomas Bächler wrote:
> Error and inexperience can occur while learning. If you upload to the
> AUR, I expect you to have polished and finished material, not your first
> draft.
>
> There's enough places with kind people who wi
On 01/05/2014 08:07 AM, Kalrish Bäakjen wrote:
> These were all the ideas. If you haven't understood something, please
> ask. Thanks,
> Kalrish
All are good ideas, but I think they work against simplicity that Arch tries to
maintain. In several cases there are multiple library versions available o
On 12/31/2013 12:51 AM, Sébastien Leblanc wrote:
> I would advise against doing that, considering that there are at least a
> handful of packages (can't name them) that have broken or otherwise
> malfunctioning Makefiles when run in parallel.
There are more than a few. If you get a PKGBUILD from
I didn't realize what you explain. However, there's no need to use
MAKEFLAGS inside the PKGBUILD; it seems 'make' automatically takes its
value from the environment if it is present.
With respect to the default value, I think it is a sane default to use
'nproc'; PKGBUILDs for applications that can
>
> hi
MAKEFLAGS in makepkg.conf is disabled (#) by default. add makeflags
variable like "--parellel-jobs=${MAKEFLAGS/-j}" in PKGBUILD only gets
errors (or not work).
i think the best method is set (and enable by default) MAKEFLAGS with nproc
value internally in makepkg tools (like MAKEFLAGS="j$
Well, my example was about a major API change. Another example would be
Python: we have version 2 and version 3, and both are used. If we had
switched to a Python3-only bleeding-edge setup, we would have ended up with
a big breakage. As we needed both, we renamed the old Python to make it
able to c
My goal was to make it generic. SCons and Waf support the "-j" option, but
that is coincidental. MAKEFLAGS is for make; why tweak it to make it work
with other build systems? And, if other build systems support some options
(for debugging, for output supression, for whatever), we need a way to tell
2014/1/5 Kalrish Bäakjen :
> Hello,
>
> Thanks for your explanation. I understand that it's not possible to
> maintain every version of a package (and, as you've pointed out, it goes
> against The Arch Way). However, it could still be useful for AUR packages,
> or even official ones (I can't check
On 6 January 2014 02:11, SpinFlo wrote:
> Hi
>
> waf have internal multithreading detection, no need add job options
That may be true, but it does support a job option. [1] I also don't
get the point of this topic, since $MAKEFLAGS simply contains a
hyphen, a character, and a number:
--parellel-
On Sun, 2014-01-05 at 18:59 +0100, Kalrish Bäakjen wrote:
> Hello,
>
> I'm sorry for the confusion. A little research reveals that make
> automatically recognises the MAKEFLAGS environmental variable. (I didn't
> know it, and I used to add $MAKEFLAGS to each make invocation.)
>
> I agree that a c
Hi
waf have internal multithreading detection, no need add job options
greetings
Hello,
I'm sorry for the confusion. A little research reveals that make
automatically recognises the MAKEFLAGS environmental variable. (I didn't
know it, and I used to add $MAKEFLAGS to each make invocation.)
I agree that a change in makepkg.conf should reflect a change in the
base-devel group. H
On Sun, 2014-01-05 at 17:55 +0100, Kalrish Bäakjen wrote:
> Hello,
>
> Some projects (e.g., mpv, in community) are moving from Autotools to other
> build systems. I think we should create a JOBS variable indicating the
> number of parallel jobs, leaving MAKEFLAGS for make-specific options. We
> co
Hello,
Some projects (e.g., mpv, in community) are moving from Autotools to other
build systems. I think we should create a JOBS variable indicating the
number of parallel jobs, leaving MAKEFLAGS for make-specific options. We
could also implement SCONSFLAGS, WAFFLAGS,… although that may be a bit
p
Hello,
Thanks for your explanation. I understand that it's not possible to
maintain every version of a package (and, as you've pointed out, it goes
against The Arch Way). However, it could still be useful for AUR packages,
or even official ones (I can't check it, but I was told that Arch keeps
off
On Sun, Jan 5, 2014 at 3:07 PM, Kalrish Bäakjen
wrote:
>
> Hello,
>
> Before starting, I'd like to remind that we're all humans, so we can
> discuss these ideas politely and making use of nothing more than
> reason. I am NOT a pedantic person looking to impose my will; please,
> excuse me if you f
Hello,
Before starting, I'd like to remind that we're all humans, so we can
discuss these ideas politely and making use of nothing more than
reason. I am NOT a pedantic person looking to impose my will; please,
excuse me if you feel I'm doing it. I hope this turns into an
interesting conversation,
21 matches
Mail list logo
