Re: [Tinycc-devel] Roadmap for 0.9.26?

[Thomas Preud'homme]

Le mercredi 18 mai 2011 00:39:29, grischka a écrit :
> Thomas Preud'homme wrote:
> > I updated the Changelog a bit, see last commit.
> > 
> > I would certainly remove the entry about support for indirect functions
> > as external if needed. It's a very small patch which doesn't deserve
> > credit. I put it here in the first place only because lots of questions
> > were asked on the ML about this.
> 
> What's an "indirect function", anyway?
I don't remember where I found this name, and I agree the description is bad. 
It references the STT_GNU_IFUNC relocations. That is relocation where a 
function is called and the return value of the function is used for relocating 
the symbol. It was really a dumb patch which just add STT_GNU_IFUNC to the 
list of accepted symbols type when linking.
> 
> I'd suggest to remove everything that users can't understand.
> (e.g. tcc_open_bf, __TRY__, "Split libtcc1.a build", ...)
> 
> However I think we should keep reverse order in time, that is last
> added features at top.
Ok
> 
> >> Anyway, I do not plan to review commits again this time so we will just
> >> go with current "mob" state as is, unless otherwise suggested.
> > 
> > Maybe for next branch we could help you by using some home-made tagging,
> > like Fix: commit_sha1 lines. This way you know which commit to merge
> > (and you would take the commit message of the first commit in a chain).
> > I should be relatively easy to write a script to automate that.
> 
> Automate what?  I'll just reset master to current mob, in fact I just
> did it.  We can still add more commits of course.   Of course it is
> also still possible to remove commits and to rebuild the entire branch
> since last release, but I don't plan to do some such myself.
If I understood correctly, before you used to do some review of the commits 
before including them in master branch. I guess the actions taken was mainly 
discard, split and merge. If you still consider this filtering as valuable (I'm 
not convinced we should rewrite history when merging in master branch) we 
could at list automate the merge actions and maybe some of the discards. This 
could be done with MergeWith: sha1 and Discard: sha1 tags. When a patch fix a 
bug/regression of a previous patch we would then add a MergeWith: 
sha1_previous_commit (or Fixup: sha1).
> 
> Btw, as to your last commit with Makefiles
> http://repo.or.cz/w/tinycc.git/commitdiff/eb152022a0359841266c0f37022e4c7ad
> 08d1f85
> 
>     +export LIBTCC1
> I don't think using export makes sense since the top-level Makefile is
> already included (at tests/Makefile:15).
> 
>      +ifdef LIBTCC1
> LIBTCC1 may be empty but defined, as from Makefile:142:
>     LIBTCC1=
> 
> --- grischka
The thing is LIBTCC1 is defined conditionnally, only if it's the main Makefile 
being run (see the ifeq($(TOP),.) near the top). I wasn't sure I could change 
this without breaking anything so I used export to just make LIBTCC1 visible.

Best regards,

Thomas Preud'homme