[llvm-dev] [cfe-dev] Fwd: Raising CMake minimum version to 3.4.3

[John Reagan via llvm-dev]

It depends on the extent of our changes and the extent of the yearly differences in CMake.   Some might merge easily, some might require re-engineering if the underlying code has major changes.  Having a “fetch me a shrubbery” exercise once a year and hope we aren’t surprised is just something I’d rather not have to do.  We already have to worry about any out-of-tree merges into newer LLVMs.  At some point as we get farther along, I’ll come back here and see what sort of stuff we can check into the tree.  For example, getting our own triple into the tree would be a good start.  However, I suspect we’re over a year away from any of those discussions.

 

Of course the real solution would be to work with the CMake folks and provide/support some OpenVMS support or at least follow THEIR development discussions.  Just more work for my small team.

 

 

 

From: James Y Knight [mailto:jyknight at google.com] 
Sent: Tuesday, May 03, 2016 9:56 AM
To: John Reagan
Cc: llvm-dev; llvm-dev-request at lists.llvm.org
Subject: Re: [llvm-dev] [cfe-dev] Fwd: Raising CMake minimum version to 3.4.3

 

It sounds like your problem is with having cmake working at all, not which version is required...So I'm not sure how requiring an upgrade every year could make that any worse.

 

If anything, I'd expect you to need a newer version in order to get porting changes.

 

On Mon, May 2, 2016 at 1:48 PM, John Reagan via llvm-dev <llvm-dev at lists.llvm.org> wrote:

As one of the OS' without current CMake support, I'm closely watching this discussion.  We currently have LLVM 3.4.2 hosted on OpenVMS Itanium (as a host only, x86 target) using configure/make with little hassle.  We plan to port CMake to OpenVMS, but that has been trickier than you'd think (others have tried, I haven't found anybody who has done it).  Looks like I'll want to visit the cmake-developers list to as we get farther along.

The "lets update every year just because" does have ripple effects for us non-traditional platforms.

John



_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160503/ee9500dc/attachment.html>