Re: wrc: change -J to -I-

[Alexandre Julliard]

"Dimitrie O. Paun"  writes:
> Cleanup a bit the command line.
> I know, I've introduced -J but I did it under time pressure,
> I never liked it :). It seems to me -I- is more intuitive,
> and cleans up the options space for stuff that we actually
> need. Moreover, this option is relevant mostly for Wine,
> so it's better if it doesn't use on of the precious letters.

I think this will be confusing, -I- means something slightly different
in gcc. I'd suggest fixing the dependency on getopt_long so that we
can have long options without having to always introduce a short
option too. Then we can get rid of -J and simply use --nostdinc.

wrc: change -J to -I-

[Dimitrie O. Paun]

On 26 Feb 2003, Alexandre Julliard wrote:
> I think this will be confusing, -I- means something slightly different
> in gcc. I'd suggest fixing the dependency on getopt_long so that we
> can have long options without having to always introduce a short
> option too. Then we can get rid of -J and simply use --nostdinc.

Sorry, I knew I've seen -I- before, but I couldn't remember what it
meant. You are right, if it has already a semantics in gcc, we need
to stick to that.

BTW, can we have a little static lib that we can link to wrc where
we can put the getopt_long code? It's needed in a bunch of places...

wrc: change -J to -I-

[Alexandre Julliard]

"Dimitrie O. Paun"  writes:
> BTW, can we have a little static lib that we can link to wrc where
> we can put the getopt_long code? It's needed in a bunch of places...

Sure, but there's no need for a getopt-specific library, it can use
the normal portability mechanisms of libwine (though I'm planning to
split the portability bits of libwine into a separate lib, but that's
a different issue...)

wrc: change -J to -I-

[Dimitrie O. Paun]

On 26 Feb 2003, Alexandre Julliard wrote:
> Sure, but there's no need for a getopt-specific library, it can use
> the normal portability mechanisms of libwine (though I'm planning to
> split the portability bits of libwine into a separate lib, but that's
> a different issue...)

Oh no, I didn't mean a getopt-specific library. I was just under the
impression that you didn't want the tools (such as wrc) be linked
with libwine, since I've noticed that port.h disables the usage
of certain functions for which we already have alternative implementations
in libwine (like strcasecmp). But that was just a cursory look,
maybe I misread that. But also, IIRC, I've submitted something
adding a getopt_long to libwine, but you opted for the current scheme:

http://www.winehq.com/hypermail/wine-patches/2002/12/0063.html

Sure, it was just the shell :), but would building on that work for you?

wrc: change -J to -I-

[Alexandre Julliard]

"Dimitrie O. Paun"  writes:
> Oh no, I didn't mean a getopt-specific library. I was just under the
> impression that you didn't want the tools (such as wrc) be linked
> with libwine, since I've noticed that port.h disables the usage
> of certain functions for which we already have alternative implementations
> in libwine (like strcasecmp). But that was just a cursory look,
> maybe I misread that.

No, it's the general idea, but the fact is that at this point most
tools link with libwine anyway. That's one of the things I'm planning
to change with a separate portability library.
> But also, IIRC, I've submitted something
> adding a getopt_long to libwine, but you opted for the current scheme:
>
> http://www.winehq.com/hypermail/wine-patches/2002/12/0063.html
>
> Sure, it was just the shell :), but would building on that work for you?

Yes, that's the way to do it, except it has to be implemented, not
stubbed out. The idea is that port.[ch] provides an emulation of the
missing functions so that people writing the code don't need to worry
about whether they exist or not. But if the replacement is broken then
we very much want the caller to be aware of that; which is why I put
the #ifdefs in wrc so that it's explicit that long options don't work
if configure didn't find getopt_long().

wrc: change -J to -I-

[Dimitrie O. Paun]

On 26 Feb 2003, Alexandre Julliard wrote:
> Yes, that's the way to do it, except it has to be implemented, not
> stubbed out. The idea is that port.[ch] provides an emulation of the
> missing functions so that people writing the code don't need to worry
> about whether they exist or not. But if the replacement is broken then
> we very much want the caller to be aware of that; which is why I put
> the #ifdefs in wrc so that it's explicit that long options don't work
> if configure didn't find getopt_long().

Of course, I just sent that patch in to see if that was the direction
you wanted to go in. I was expecting, 'yeah, but implement that as well' :)

Not a problem, now I know what you want, I'll try to find some time
to do it.

wrc: change -J to -I-

[Steven Edwards]

> > BTW, can we have a little static lib that we can link to wrc where
> > we can put the getopt_long code? It's needed in a bunch of places...
>
> Sure, but there's no need for a getopt-specific library, it can use
> the normal portability mechanisms of libwine (though I'm planning to
> split the portability bits of libwine into a separate lib, but that's
> a different issue...)

Are we going to be frezing these interfaces anytime soon? I know it may still be a while before
0.9/1.0 but it would be nice on the ReactOS side. I know I ask a lot =/

Thanks
Steven

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

wrc: change -J to -I-

[Alexandre Julliard]

Steven Edwards  writes:
> Are we going to be frezing these interfaces anytime soon? I know it may still be a while before
> 0.9/1.0 but it would be nice on the ReactOS side. I know I ask a lot =/

It's unlikely they will get frozen before 0.9. We should probably
start to use symbol versioning by 0.9 too, but I'm not sure how well
this would work on ReactOS...

wrc: change -J to -I-

[Mike Hearn]

> It's unlikely they will get frozen before 0.9. We should probably
> start to use symbol versioning by 0.9 too, but I'm not sure how well
> this would work on ReactOS...

Is there a reason you're considering symvers rather than simply bumping
the soname when ABI compatability is broken?

Is it a case of "well wine is huge, so we can't really expect people to
install multiple versions"? I think that's the reasoning the libc people
use, but as the bulk of Wine is effectively abi stable anyway thanks to
the 'soft, I don't see it as being such a big deal.

thanks -mike

wrc: change -J to -I-

[Alexandre Julliard]

Mike Hearn  writes:
> Is there a reason you're considering symvers rather than simply bumping
> the soname when ABI compatability is broken?
>
> Is it a case of "well wine is huge, so we can't really expect people to
> install multiple versions"? I think that's the reasoning the libc people
> use, but as the bulk of Wine is effectively abi stable anyway thanks to
> the 'soft, I don't see it as being such a big deal.

The wine internal libraries are still about a megabyte of code, and
it's silly to duplicate all of that whenever a single function
changes. Symbol versioning is much better solution to that problem,
and I don't see much reason for not using it (except on platforms that
don't support it of course).

wrc: change -J to -I-

[Mike Hearn]

> The wine internal libraries are still about a megabyte of code, and
> it's silly to duplicate all of that whenever a single function
> changes. Symbol versioning is much better solution to that problem,
> and I don't see much reason for not using it (except on platforms that
> don't support it of course).

Yes, fair enough. I hadn't realised that while libwine is fairly small,
libwine_unicode is huge (not sure what it does, but i expect i'll find
out soon enough).

I don't really have any objection to symvers, other than it does mean
it's harder to eliminate "dead" legacy code. That's only really a
problem if the library changes fairly often though, and even then it's
not such a problem these days.