guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/7] gnu: Add llvm-for-extempore.


From: Ricardo Wurmus
Subject: Re: [PATCH 4/7] gnu: Add llvm-for-extempore.
Date: Fri, 16 Sep 2016 15:47:09 +0200
User-agent: mu4e 0.9.16; emacs 25.1.1

Thompson, David <address@hidden> writes:

> On Wed, Sep 14, 2016 at 5:38 AM, Ricardo Wurmus <address@hidden> wrote:
>> * gnu/packages/llvm.scm (llvm-for-extempore): New variable.
>> ---
>>  gnu/packages/llvm.scm | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/gnu/packages/llvm.scm b/gnu/packages/llvm.scm
>> index a9eba79..b55a200 100644
>> --- a/gnu/packages/llvm.scm
>> +++ b/gnu/packages/llvm.scm
>> @@ -3,6 +3,7 @@
>>  ;;; Copyright © 2015 Mark H Weaver <address@hidden>
>>  ;;; Copyright © 2015 Ludovic Courtès <address@hidden>
>>  ;;; Copyright © 2016 Dennis Mungai <address@hidden>
>> +;;; Copyright © 2016 Ricardo Wurmus <address@hidden>
>>  ;;;
>>  ;;; This file is part of GNU Guix.
>>  ;;;
>> @@ -267,3 +268,10 @@ code analysis tools.")
>>  (define-public clang-3.5
>>    (clang-from-llvm llvm-3.5 clang-runtime-3.5
>>                     "0846h8vn3zlc00jkmvrmy88gc6ql6014c02l4jv78fpvfigmgssg"))
>> +
>> +(define-public llvm-for-extempore
>> +  (package (inherit llvm-3.7)
>> +    (source
>> +     (origin
>> +       (inherit (package-source llvm-3.7))
>> +       (patches (list (search-patch "llvm-for-extempore.patch")))))))
>
> This could use a comment explaining the rationale.  Also, you forgot
> to include the patch file in this commit.

Oh, I did indeed forget it.  I’ve added it and put a long comment to the
top, which I’ll quote here:

~~~~~~~~~~~~~~
This patch to LLVM is required by the developers of the Extempore language.
The following explanation was posted to the address@hidden
mailing list:

"There is an assumption in the parser that all definitions occur within the
same compilation unit - i.e. the parser has local state about what has been
parsed in this unit of work.  Extempore obviously does lots of little units
rather than one big unit and this causes problems for named types that were
defined in another unit - which they always are.  The patch simply checks the
current module to see if the type has been previously defined, and intervenes
appropriately if it has."

Message-ID: <address@hidden>
~~~~~~~~~~~~~~

Thanks for the review!

~~ Ricardo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]