<div dir="ltr">I have my own Pascal compiler frontend. So I need to keep up with API changes in the LLVM API, but not the Clang changes. I don't do what Marcello suggests - not because I think it's a bad idea, just because I haven't made the effort to set it up.<br><br>I find that the API breaks once in a while - the other day, when I moved to latest version, I found that the IRBuilder::CreateCall{2, 3,4,5} had been removed, so I needed to change that bit of code. <br><br>My experience, however, is that it's not that often that things change.<div><br></div><div>--</div><div>Mats</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 June 2015 at 03:26, Marcello Maggioni <span dir="ltr"><<a href="mailto:mmaggioni@apple.com" target="_blank">mmaggioni@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There will always be unexpected API changes and there’s no way to get around that. You will have to use the API of course.<br>
<br>
If you want to follow top of tip you need to setup some kind of automerging environment that merges with master every night and in the morning if you are lucky you have everything working and if you are unlucky somebody changed the number of parameters of the constructor of some classes you use and you will need to fix that to continue the merge.<br>
Some changes are more subtle … the API remains the same, but the semantic of some parameter changes and you will get probably test errors you will have to figure out why started failing.<br>
<br>
Doing it daily is the best thing in my experience to keep it going. There are bad periods and good periods with resepect to changes. Certainly though if you leave it unmerged for two or more months and then you want to try and merge just wait to find yourself in a lot of pain … (experience again :P )<br>
<br>
Of course if you are working alone and diligent enough you can do it manually every day, but setting up something automatic always helps in keeping up with your initial proposal :)<br>
<br>
Cheers,<br>
Marcello<br>
<div class="HOEnZb"><div class="h5"><br>
> On 13 Jun 2015, at 18:53, <a href="mailto:rzaghi@mosaic3dx.com">rzaghi@mosaic3dx.com</a> wrote:<br>
><br>
> Hey everyone on cfe-dev<br>
><br>
> New list member but an old admirer of your great work here.<br>
><br>
> I am planning the implementation of a set of C++ language extensions which we hope to be used in a [non-compiler related] research project at the University of Cambridge next year.<br>
><br>
> Naturally, I chose Clang to do this. However, I have an "engineering" question.<br>
><br>
> The extensions are, as you would imagine, not part of the standard - and I had like to add the word "yet", hehe.<br>
><br>
> Given the potential invasiveness of some of the features and the pace of changes to the code base, I am left with no answer as to how I can keep up with the pace of the change and whether such requirements have been taken into account in the internal design of the front end, by any chances?<br>
><br>
> Basically, I do not want to be in a position where we have working version of the extensions next year but based on a version of the front end which is one year old.<br>
><br>
> It may help to give you a flavour of what some of these changes may look like.<br>
><br>
> As an example, the extension would allow us to "tag" some identifiers in the code as follows:<br>
><br>
> class CLXYZ {<br>
> public:<br>
>  int <tag1> x;<br>
> };<br>
><br>
> The identifier tagged as such is later picked at one of the phases and operated on.<br>
><br>
> So what is the best practice here? Other than rebasing every so often?<br>
><br>
> Appreciate your input and advice.<br>
> - Ramin<br>
><br>
><br>
> (ps, not so related to my question but we call this "tagged-programming" paradigm. Actually we hope that the combination of these extensions can eventually help programmers in scenarios as the very question I am asking above!).<br>
><br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>