Hi Lluís,
> Mh I think the manual mainly helps to tell people "please read the
> manual", when they ask the question. ;)
yes, that is true. We cannot expect that people will read the entire
user manual before they begin to hack Nix expressions.
However, Google's web crawler does read those man
Not sure how correct this is, but I grepped my nixpkgs in attempted to
quantify this a bit, here are the results:
$ grep -R configureFlags . | wc -l
951
$ grep -R configureFlags . | grep -E '\$[^{]' | wc -l
156
Marc Weber writes:
> 1) I remember having hit this case, too.
>
> 2) If we don't wan
Excerpts from Lluís Batlle i Rossell's message of Tue May 21 14:11:46 +0200
2013:
> > configureFlags = "--whoami-expression=$USER";
> > configureFlags = "--initial-array=( 'state 1' 'state 5' )";
Let's start from scratch:
configureFlags is a list of space separated arguments, right?
So we alr
1) I remember having hit this case, too.
2) If we don't want to break builds, we could at least change setup.sh
to test whethet it countains $out, if it does, cause error message:
use preConfigure = ''
...
''
instead.
About changing semantics: I don't think it would affect any existing
buil
On Tue, May 21, 2013 at 12:57:10PM +0200, Peter Simons wrote:
> Hi Lluís,
>
> >> Maybe it would be sufficient to document the current behavior in
> >> more detail?
> >
> > Many people hit this problem, when they started using mkDerivation.
>
> yes, that is true. I'm just not convinced that ch
Hi Lluís,
>> Maybe it would be sufficient to document the current behavior in
>> more detail?
>
> Many people hit this problem, when they started using mkDerivation.
yes, that is true. I'm just not convinced that changing the semantics of
configureFlags is the best solution for this issue. IM
On Tue, May 21, 2013 at 11:33:26AM +0200, Peter Simons wrote:
> A change to the semantics of 'configureFlags' has significant potential
> to break existing builds. Why would we take that risk? What exactly do
> we gain?
>
> Personally, I've rarely had the need to pass $out in configureFlags, and
A change to the semantics of 'configureFlags' has significant potential
to break existing builds. Why would we take that risk? What exactly do
we gain?
Personally, I've rarely had the need to pass $out in configureFlags, and
if I do need that, then
preConfigure = ''configureFlags="--foo=$out/e
On 19 May 2013 12:12, Vladimír Čunát wrote:
> On 05/19/2013 12:05 PM, Bjørn Forsman wrote:
>>
>> On 19 May 2013 09:37, Lluís Batlle i Rossell wrote:
>>>
>>> On Sat, May 18, 2013 at 07:11:32PM +0200, Bjørn Forsman wrote:
preConfigure = ''configureFlags="--foo=$out/etc/foo.cfg"'';
>>>
On 05/19/2013 12:05 PM, Bjørn Forsman wrote:
On 19 May 2013 09:37, Lluís Batlle i Rossell wrote:
On Sat, May 18, 2013 at 07:11:32PM +0200, Bjørn Forsman wrote:
preConfigure = ''configureFlags="--foo=$out/etc/foo.cfg"'';
That's what we all end up doing. :)
Hehe, Ok I see :-)
But how ab
On 19 May 2013 09:37, Lluís Batlle i Rossell wrote:
> On Sat, May 18, 2013 at 07:11:32PM +0200, Bjørn Forsman wrote:
>>preConfigure = ''configureFlags="--foo=$out/etc/foo.cfg"'';
>
> That's what we all end up doing. :)
Hehe, Ok I see :-)
But how about "eval configureFlags=$configureFlags" (o
On Sat, May 18, 2013 at 07:11:32PM +0200, Bjørn Forsman wrote:
>preConfigure = ''configureFlags="--foo=$out/etc/foo.cfg"'';
That's what we all end up doing. :)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/li
Hi,
I noticed today that $out in configureFlags is not expanded. So this
will not do what you'd think:
configureFlags = "--foo=$out/etc/foo.cfg";
Instead, it will pass --foo=$out/etc/foo.cfg (literally) to configure.
(And if using ${out}, nix will complain about undefined variable
'out'.)
T
13 matches
Mail list logo
