On Mon, Oct 03, 2011 at 08:51:06PM +0200, grischka wrote:
> Kirill Smelkov wrote:
>> On Sat, Oct 01, 2011 at 12:36:23AM +0200, grischka wrote:
>>> Kirill Smelkov wrote:
> I have it as git branch btw. If anyone is interested I could push
> it on repo.or.cz.
Yes, I'm interested. Could yo
Kirill Smelkov wrote:
On Sat, Oct 01, 2011 at 12:36:23AM +0200, grischka wrote:
Kirill Smelkov wrote:
I have it as git branch btw. If anyone is interested I could push
it on repo.or.cz.
Yes, I'm interested. Could you please do so? Thanks.
Well, now I don't want to push it into our repo, becau
Rob Landley wrote:
The part I boggle at is that you honestly believe that single character
global function names are a good idea, which scale to large codebases.
This is one of many reasons why I think your technical judgement sucks.
Well, code has a function and a message and the message with,
On Sat, Oct 01, 2011 at 12:36:23AM +0200, grischka wrote:
> Kirill Smelkov wrote:
>>> I have it as git branch btw. If anyone is interested I could push
>>> it on repo.or.cz.
>>
>> Yes, I'm interested. Could you please do so? Thanks.
>
> Well, now I don't want to push it into our repo, because it wo
On 09/30/2011 05:50 PM, grischka wrote:
> Rob Landley wrote:
>> There were a functions named g() and o() which were IMPOSSIBLE to
>> grep for...
>
> Because you don't know how to use grep.
Because I don't want to drop out of my text editor and grep from the
command line, and doing the search as a
Rob Landley wrote:
There were a functions named g() and o() which were IMPOSSIBLE to
grep for...
Because you don't know how to use grep.
For the patches in question, I'm pretty sure he _specifically_ told me
that he _didn't_ want colon separated search paths.
I'm pretty sure we never talked
Kirill Smelkov wrote:
I have it as git branch btw. If anyone is interested I could push
it on repo.or.cz.
Yes, I'm interested. Could you please do so? Thanks.
Well, now I don't want to push it into our repo, because it would
just bloat everybody's copy. If you want to I could push it into
yo
On 09/30/2011 10:25 AM, Kirill Smelkov wrote:
>>> I have it as git branch btw. If anyone is interested I could push
>>> it on repo.or.cz.
>>
>> I thought your current maintainer policy was zero editorial control,
>> just let random strangers form a slush pile in the mob branch and then
>> ship it?
Grischka, Rob, All,
On Sat, Jul 09, 2011 at 09:28:21PM +0200, grischka wrote:
> Rob Landley wrote:
>> On 07/07/2011 01:22 PM, grischka wrote:
>>> Anyway. As to the general issue with search paths, it would be good
>>> to find something clearer and more flexible.
>>
>> A quick check finds:
>>
>>
Rob Landley wrote:
I have it as git branch btw. If anyone is interested I could push
it on repo.or.cz.
I thought your current maintainer policy was zero editorial control,
just let random strangers form a slush pile in the mob branch and then
ship it? (I can't say I've been reading the list ve
On 07/09/2011 02:28 PM, grischka wrote:
> Rob Landley wrote:
>> On 07/07/2011 01:22 PM, grischka wrote:
>>> Anyway. As to the general issue with search paths, it would be good
>>> to find something clearer and more flexible.
>>
>> A quick check finds:
>>
>> http://landley.net/hg/tinycc/rev/f304c7e
On Saturday 09 July 2011, 21:28:21, grischka wrote:
> Rob Landley wrote:
> > http://landley.net/hg/tinycc/rev/f304c7e3de8d
> > http://landley.net/hg/tinycc/rev/374af493d0ac
> > http://landley.net/hg/tinycc/rev/647f1a3feb8b
> > http://landley.net/hg/tinycc/rev/22b60bb22c83
> > http://landley.net/hg/
Thomas Preud'homme wrote:
As I understand it is possible to support multilib without any special
code in tcc. Without CONFIG_TCC_MULTILIB_SUBDIR, AFF_MULTILIB,
CONFIG_TCC_EXTRA_LDDIR, CONFIG_TCC_INCSUBDIR, just without anything
"MULTI_EXTRA_SUB" whatsoever.
Do you think that is possible?
Yes, I
Le dimanche 10 juillet 2011 18:05:57, grischka a écrit :
> Thomas Preud'homme wrote:
> > I wrote the code yesterday. Please take a look. Still missing is the
> > handling of elf_interp but this must be added anyway without this
> > option.
>
> Well, to me the better patches are those that make the
Thomas Preud'homme wrote:
I wrote the code yesterday. Please take a look. Still missing is the handling
of elf_interp but this must be added anyway without this option.
Well, to me the better patches are those that make the code smaller
rather than bigger ;)
As I understand it is possible to s
Le samedi 9 juillet 2011 20:44:47, grischka a écrit :
> Thomas Preud'homme wrote:
> > First let's focus on multilib as you said.
>
> Actually I said "multilib" because you said "multilib". Which
> means that I've no idea really what it means.
Ah? Ok nevermind. Usually I talk about multiarch but t
Rob Landley wrote:
On 07/07/2011 01:22 PM, grischka wrote:
Anyway. As to the general issue with search paths, it would be good
to find something clearer and more flexible.
A quick check finds:
http://landley.net/hg/tinycc/rev/f304c7e3de8d
http://landley.net/hg/tinycc/rev/374af493d0ac
http://
Thomas Preud'homme wrote:
First let's focus on multilib as you said.
Actually I said "multilib" because you said "multilib". Which
means that I've no idea really what it means.
The requirement for multilib is suffix all path from search paths
(whatever are these search paths: include search
On 07/07/2011 01:22 PM, grischka wrote:
> Anyway. As to the general issue with search paths, it would be good
> to find something clearer and more flexible.
A quick check finds:
http://landley.net/hg/tinycc/rev/f304c7e3de8d
http://landley.net/hg/tinycc/rev/374af493d0ac
http://landley.net/hg/tiny
Le vendredi 8 juillet 2011 18:42:01, Thomas Preud'homme a écrit :
[SNIP]
>
> === Sketch for a (hopefully) better solution ===
>
> One thing to remember though is that almost all files (headers, object,
> archive, but not ld.so) are included via
> tcc_add_file_internal(s1,filename,flags). So if tc
Le jeudi 7 juillet 2011 20:22:30, grischka a écrit :
[SNIP fixed issues]
> Anyway. As to the general issue with search paths, it would be good
> to find something clearer and more flexible.
>
> Of course we want to support latest systems and multilib and whatnot.
> But all this "CONFIG_stuff" is
Le jeudi 7 juillet 2011 20:22:30, vous avez écrit :
> Thomas Preud'homme wrote:
> > And also sorry for introducing so stupid bugs.
>
> It was not your fault, it is all strtok's fault. ;)
>
> As to the new version:
>
> - I don't seem to like my own suggestion 'tcc_split_path_components'.
>Wha
Thomas Preud'homme wrote:
And also sorry for introducing so stupid bugs.
It was not your fault, it is all strtok's fault. ;)
As to the new version:
- I don't seem to like my own suggestion 'tcc_split_path_components'.
What about just 'tcc_split_path'?
- The function shouldn't be placed in
Le jeudi 7 juillet 2011 00:06:37, grischka a écrit :
> Thomas Preud'homme wrote:
> >> Also, I'd claim that using strtok is somehow un-tcc'ish, seen that
> >> there are zero occurrences anywhere else. ;)
> >
> > Ah. Then what tcc'ish function should I use?
>
> The one that you write yourself ;) S
---
> > From: tinycc-devel-bounces+eligis=orange...@nongnu.org
> > [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of
> > grischka
> > Sent: jeudi 7 juillet 2011 02:43
> > To: tinycc-devel@nongnu.org
> > Subject: Re: [Tinycc-devel] Allow conf
Of
> grischka
> Sent: jeudi 7 juillet 2011 02:43
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] Allow configuration of tcc libraries search
> path
>
> Btw I don't like this one:
>
>Make examples' shebang use target tcc
configuration of tcc libraries search path
Btw I don't like this one:
Make examples' shebang use target tcc bindir path
http://repo.or.cz/w/tinycc.git/commitdiff/cb2138f8b098feb1b51a407343a4b99e25
d5b506
It looks like horrible overhead. I mean these are just examples meant to be
Btw I don't like this one:
Make examples' shebang use target tcc bindir path
http://repo.or.cz/w/tinycc.git/commitdiff/cb2138f8b098feb1b51a407343a4b99e25d5b506
It looks like horrible overhead. I mean these are just examples
meant to be studied in the first place, and not to run out of the
Thomas Preud'homme wrote:
Also, I'd claim that using strtok is somehow un-tcc'ish, seen that
there are zero occurrences anywhere else. ;)
Ah. Then what tcc'ish function should I use?
The one that you write yourself ;) Say along the lines of
while (*p && *p != ':')
++p;
Reason why
Le mardi 5 juillet 2011 19:04:22, grischka a écrit :
> Thomas Preud'homme wrote:
> > #ifdef CONFIG_TCC_EXTRA_LDDIR
> >
> > {
> >
> > const char delim[] = ":";
> > char *tok, *tok_extra_libdir = NULL, *tok_save_ptr,
> > *extra_libdir_str; size_t toklen = 0, old_tokl
Thomas Preud'homme wrote:
#ifdef CONFIG_TCC_EXTRA_LDDIR
{
const char delim[] = ":";
char *tok, *tok_extra_libdir = NULL, *tok_save_ptr, *extra_libdir_str;
size_t toklen = 0, old_toklen = 0;
extra_libdir_str = tcc_strdup(CONFIG_TCC_EXTRA_LDDIR);
tok = s
Greetings everyone,
we are currently switching to multiarch [0][1] in Debian and I had the need to
allow tcc to search libraries in several directories and also needed to be
able to change the search directory for ld.so and crt*.o files.
[0] http://wiki.debian.org/Multiarch/TheCaseForMultiarch
32 matches
Mail list logo
