This
should work as long as you can at least at some point catch
up with the LLVM release schedule. At some point LLVM may settle
on a stable interface but that does not appear to be in their
current
plans. Anyhow, good luck!
On 2/2/19 8:18 AM, Julien Bect wrote:
Le
01/02/2019 à 23:25, Mike Miller a écrit :
On Fri, Feb 01,
2019 at 22:45:53 +0100, Julien Bect wrote:
You're talking
about "old versions" of LLVM, but LLVM 3.8 -- 4.0 are in fact
the version currently available in Debian stretch. (I know,
not in
fedora...)
IMHO, the development branch of Octave should try to target
"current"
versions of LLVM, where "current" is 7.0 and 8.0-rc1 at the
moment.
Targeting the Debian stable version of LLVM seems less than
effective.
Please consider that by the time the current default branch
becomes
Octave 6 (probably about a year from now), it would be most
useful to
everyone if it worked with LLVM 9 and/or 10 (probably releasing
September 2019 and March 2020, respectively).
Sure, I am not "targeting the Debian stable version". Not at all.
I am just noting that : 3.8 -- 3.9 is the range of LLVM versions
that we currently can build with. Then, I progressively try to
extend this range (as opposed to : making it work with 4.0 while
breaking what currently works with 3.8 - 3.9).
I believe that for 4.0 and 5.0 it will boil down to a few
autoconfs macros **once** the required change will have been
determined... (By the way, note that 4.0 and 5.0 are not *very* old, since they were releases
in March and September 2017, respectively.)
Then I will try to extend to 6.0 (March 2018) and 7.0 (September
2018) but I have no idea about the kind of problem that I will
meet then.
Proceeding like this, step by step, is easier for me than breaking
everything and trying to make it work wih LLVM 7.0 or 8.0-rc1
directly, because my understanding of LLVM, JIT, etc. is very
limited and I am learning along the way...
|