[Top][All Lists]

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

Re: [Tinycc-devel] const_wanted

From: Thomas Preud'homme
Subject: Re: [Tinycc-devel] const_wanted
Date: Mon, 1 Aug 2011 16:56:52 +0200
User-agent: KMail/1.13.7 (Linux/2.6.39-2-amd64; KDE/4.6.5; x86_64; ; )

Le lundi 1 août 2011 01:19:54, grischka a écrit :
> Thomas Preud'homme wrote:
> > I knew you would answer something like this. That's why I didn't apply
> > the patch straight forward.
> You did not apply the patch because you knew it doesn't work? ;)
> > I've just found this commit when searching for what made the bug
> > disappear. The "else if" should not have been removed, just the message
> > changed. Is that ok if I put back the if else with the message you want?
> > Sorry to annoy you, I'm sure it would be faster for Joe or you to patch
> > it right away but I'm trying to learn in the process.
> Since there is logically no difference between
>      else if (!local_stack)
>          error("..."):
> and the patch that you already suggested
>      if (cur_text_section == NULL)
>          error("...");
> I must assume that you already know that both will equally well
> not work. ;)
Actually no I didn't. I didn't know !local_stack and !cur_text_section were 
equivalent. I'll let Joe do it then. It'll be more efficient (in terms of lines 
of code / lines of email)
> > I'd just like to know if you would agree to add a --multiarch-
> > triplet=<triplet> switch to configure for convenience. This switch would
> > transform the various PATH from dir1:dir2 to
> > dir1/<triplet>:dir1:dir2/<triplet>:dir2.
> Sure, yes.
> If it is too troublesome to pass all stuff between configure and
> make, you could just write the paths into config.h directly from
> configure.  Do as you see fit.
> I have decided to push the patch for tcc:
>     http://repo.or.cz/w/tinycc.git/commitdiff/df9cce24
> Hope you find it useful (and that I haven't messed up too much).
Great. I reviewed the patch and it all looks good. You did all the hard work, 
now only the easy job is missing. Thank you. Note that in UNIX filename the \b 
caracter chould be part of a path and hence the \b macro you introduced 
implicitely forbid the use of \b in paths containing source to be compiled by 
tcc. Of course it's also true for the PATHSEP element. I'm not advocating for 
an escaping character though, it would quickly become a mess. I'm not saying 
the idea should be forgotten as I don't think anyone sane would use it anyway, 
but it should probably be documented somewhere.

Now I think about 3 ways for implementing this --multiarch-triplet switch. 
Could you tell me which one you prefer (or non of them if you'd like a 
solution non suggested here)?

Solution 1:

Generate the current set of (conditional) define for 
it's easy to do a loop to duplicate each path and prepend the first version 
with <triplet>.

Variant: Move the default setting in the Makefile and use patsubst or foreach 
to append <triplet> to each path.

In both cases the set of define in tcc.h would be replaced by a comment telling 
where to find the default values.

Solution 2:

Introduce a new substitution macro \t (or maybe another if we want to keep 
tabs in paths) which would copy the next path and add the <triplet> suffix if 
be defined this way on UNIXes:

#  define CONFIG_TCC_SYSINCLUDE_PATHS "\t:/usr/local/include:\t:/usr/include:

This idea came to me when seeing your \b substitution. I quite like the idea 
but it would make tcc_split_path a bit more complicated than your current 
definition, hence I only proposed it as Solution 2

Solution 3:

Use several ifdef CONFIG_TCC_MULTIARCH_TRIPLET to define 
to CONFIG_TCC_LIBPATHS for consistency). This would give something like 

#  else
#   define CONFIG_TCC_SYSINCLUDE_PATHS "\b/include;\b/include/winapi"
#  endif
# else
#  else
#   define CONFIG_TCC_SYSINCLUDE_PATHS "/usr/local/include:/usr/include:
#  endif
# endif

I suggest this one just in case but I believe it's the most ugly solution

Solution 4:

Any other idea. The goal is to avoid to have the same definition as in tcc.h 
duplicated in configure with the duplication+addition of $multiarch_triplet for 
each path.
> As a sideeffect TCC now supports colon separated strings also with
>       -L and -I
> which is slightly unusual but I think it is  acceptable as long
> as it doesn't cause problems (which I don't see).
There is one small problem as mentionned earlier. But I guess it's a 
reasonnable limitation compared to all the #ifdef people have to support both 
gcc (with specific __attribute__) and tcc
> --- grischka
Thomas Preud'homme

Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

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