Re: [Tinycc-devel] Re: TCC:cannot find -l"xyz.dll"

[lostgallifreyan]

grischka <address@hidden> wrote:
(06/04/2009 23:06)

>>>     tcc hello_win.c
>>>
>>> and it works.  Why should we recommend horrible stuff like
>>> "DOS path" and "quoted full long name paths" to newcomers?
>>>
>> Because that is what works in Windows. If it shouldn't be said as 
>> a general thing, it can still be pointed out in a Windows specific
>> place.
>
>I believe you that it works.  However typing just "tcc hello_win.c"
>works too.  So why make it more complex than it needs to be?
>

I think the issue has to do with the current working directory. Typing exact 
case without paths will work IF the current dir is TCC's base dir, but there 
are two main practises in Windows, either you set the working directory, or you 
specify exact paths. Second case is usually easiest, because the fastest call 
to a 'console' shell window is usually to a fixed working location, usually the 
desktop.

I'm not after complexity, just looking for the neatest way to be sure that a 
newcomer can fire up TCC within about three attempts at various optuions 
Windows offers. It;s when it won't work after five or more that people run out 
of ideas and start asking stuff.

>> In Windows it's common practise to drag a file to a DOS window, where 
>> the file path will write to the input. This might work for TCC's command
>> input too in WXP, I don't know, but not in W9X, and neither OS uses
>> case sensitivity in paths.
>
>With my Windows I cannot "drag a file to a DOS window".  How can
>it be common practice then?
>

It was. Thought it still was. I only use WXP rarely, but I remember it worked 
there as well as in W98. The difference is that in WXP it wil autotype a full 
path with long filenames, in W9X only the DOS '8.3' filename convention, so it 
results in things like LONGFI~1.EXT instead of Long Filename.ext.

>> Most command line tools for Windows work around this, 
>
>Sorry, how do they work around what?
>

They understand the way Windows writes paths, at least accepting enough of the 
possibilities to reduce the difficulty in accessing them. One way is to allow 
case INsensitivity for filenames and extensions, while preserving case 
sensitivity for arguments. I don't know whether the DOS 8.3 filename convention 
is a thing handled by a function built into Windows, or whether it has to be 
coded explicitly. Given that the number after the Tilde can vary, I think it 
can be fetched from the OS, the code doesn't have to guess.

>> TCC doesn't, so 
>> it's reasonable to expect that this is pointed out somewhere. The
>> simplest way is to stress the need for full, case sensitive quoted
>> paths, as that's the standard way Windows users are told, from what
>> I've seen over the last ten years or so.
> >
>> If the basic starting methods for TCC are explicitly described for 
>> Windows, the sooner newcomers can fire it up and the sooner we can
>> be expected to figure out what are our own errors.
>
>But the basic starting method for TCC is typing "tcc", on windows
>just as anywhere else.
>

Yes, if you assume that TCC's base dir is current working dir, but it's wise 
not to assume that. If a direct path, written without case sensitivity, OR 
working with drag/drop to autowrite paths in either DOS or longname format 
works, it will help a lot, Either case will help a great deal. Rememberm, it's 
not starting TCC that's hard, the trouble comes when passing files TO the 
compiler because it has very strict conditions. One that might be worth 
relaxing is allowing it to accept upper case C extensions, if that doesn't 
conflict with reserved use of those in OS's other than Windows. But better is 
if the Windows compilation of TCC will understand Windows paths better, and use 
at least one of the watys I mentioned. That would reduce the likely number of 
attempts to less that three, and should prevent most people from getting 
confused before they start.

>> Until it runs and compiles something, all bets are off, from our 
>> point of view. I'm not asking for free fish, only a guide to get
>> immediately experience of a working rod.
>
>But you can get an immediate experience with the examples, no?
>

Only after I'd tried a few things, asked questions, got an answer that worked. 
Later explorations told me more about this. If the help included a pointer or 
two for others, it will spare them this awkward start. The basis of my logic is 
that when something is thought not to work, the first question any engineer 
asks is: Did it ever work, in the context it is in now? If the answer is yes, 
it's much easier. And maybe end users won't have to call on engineers so much 
if it does work more easily the first time.

>--- grischka
>
>
>
>_______________________________________________
>Tinycc-devel mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/tinycc-devel