#pragma lib
jacob navia
in comp.std.c:
<<<<< begin quote >>>>>
The Plan9 compilers have
#pragma src "..."
#pragma lib "..."
and these are passed through to the
linker and then to the object file.
That way the linker can find the library
with the .o equivalent (don't need -l),
and the debugger can find the source code.
Dennis
<<<<< end quote>>>>>
As many people here have pointed out, the big problem with
#include <foo.lib>
is that all existing compilers would start including the source file as
text!!!
Not very bright.
I see that Denni's idea is much better to smoothly adopt this.
The conventions will be:
#pragma lib "foo"
Means:
Search in the current directory for a file called "foo.lib"
#pragma lib "foo.lib"
same as above
#pragma lib <foo.lib>
Search for a file called \lcc\lib\foo.lib
The same convention as for #include paths.
Is that now OK with you all?
I implemented this stuff today and seems to work. It could be in the next
release.
Franz Fritsche
<ja...@jacob.remcomp.fr> wrote:
>
> I see that Denni's idea is much better to smoothly adopt this.
>
Well, only for the record: Dave Hansen and Mike Caetano both came up
with a comparable idea... ;-)
On the other hand, the approach of Dennis seems to be supperior due to
its _simplicity_ (simple syntax)!
>
> The conventions will be:
>
> #pragma lib "foo"
>
GREAT!
I am looking forword to use:
#pragma lib <bignums>
and/or
#pragma lib <math>
etc.
Clearly it should be possible NOW to use this commands in the "main"
source file.
>
> Is that now OK with you all?
>
A++ (!)
:-)
F.
P.S.
"If I have seen farther, it is by standing on the shoulder
of giants." (Newton)
John
"jacob navia" <ja...@jacob.remcomp.fr> wrote in message
news:afch7q$fpp$1...@wanadoo.fr...
>
> The conventions will be:
> #pragma lib "foo"
> #pragma lib <foo.lib>
>
> Is that now OK with you all?
>
> I implemented this stuff today and seems to work. It could be in the next
> release.
Will this work for .obj files that would be included in the link phase?
#pragma lib "foo.obj" or could be #pragma obj "foo.obj"
John
John
"John" <John....@btinternet.com> wrote in message
news:afcp8c$d41c4$1...@ID-97861.news.dfncis.de...
> >
> > I implemented this stuff today and seems to work. It could be in the
next
> > release.
>
> Will this work for .obj files that would be included in the link phase?
>
> #pragma lib "foo.obj" or could be #pragma obj "foo.obj"
What I mean is say for an .obj file created with an assembler not the .obj
files created with lcc-win32.
John
Mike Caetano
> #pragma lib "foo"
> Means:
> Search in the current directory for a file called "foo.lib"
> #pragma lib "foo.lib"
> same as above
> #pragma lib <foo.lib>
> Search for a file called \lcc\lib\foo.lib
> The same convention as for #include paths.
> Is that now OK with you all?
That seems very reasonable to me and more elegant than the msvc approach
too.
Now, how about [ #pragma comment "fixme!!" ] - to send output to the
debugging window in similar fashion to #error but without throwing an error?
:-)
Mike
jacob navia
-----------------
What happens if
#pragma lib "foo.lib"
is written somewhere and no "foo.lib" is found?
I have implemented it with no complaints or warnings if the library is not
found. This way you can still include a header with this directive even if
you do not have the library
Is this OK?
Franz Fritsche
<ja...@jacob.remcomp.fr> wrote:
>
> What happens if
> #pragma lib "foo.lib"
> is written somewhere and no "foo.lib" is found?
>
> I have implemented it with no complaints or warnings if the library is not
> found.
>
I think a _warning_ should be issued!
---> This way you can still include a header with this directive even
> if you do not have the library
On the other hand, I think there _should_ should be at least some
"user-information" (feedback) if something "goes wrong". (But a
warning would be enough, I think.)
F.
Greg Comeau
Notwithstanding my other comments, this is more reasonable,
but the choice is still current dir vs "standard dir" and
for many things that is insufficient, and so many need
environment variables and/or command line options to help it.
--
Greg Comeau 4.3.0 NEWS: New Windows Backends + 'export' IN MAY!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Greg Comeau
It's been mentioned to me a number of times that we (Comeau C/C++)
should support a #warning, and along those line a #remark
along the lines of #error but with different severities.
I also seem to recall that it's been brought up in the C++0x
considerations (which is very early) and that some compilers
already have similar capabilities. As such Comeau C/C++ now
supports a #warning, and we're considering some of the other things
too, as an extension. So, your idea is not that far fetched.
Greg Comeau
If you mean that it is not checked for during so-called
compile-time, then sure, but a number of questions come up
at link time, and this is indeed so of the messy stuff I
mentioned (and now see Rev Bob devled into too) in another
message (does it go find another lib with it?, can you control
it via the command line, etc., etc.).
Greg Comeau
If the link fails, why should it be any different than any
other link failure?
Mike Caetano
news:afd4db$dhf$1...@panix3.panix.com...
> >Now, how about [ #pragma comment "fixme!!" ] - to send output to the
> >debugging window in similar fashion to #error but without throwing an
error?
> >:-)
>
> It's been mentioned to me a number of times that we (Comeau C/C++)
> should support a #warning, and along those line a #remark
> along the lines of #error but with different severities.
> I also seem to recall that it's been brought up in the C++0x
> considerations (which is very early) and that some compilers
> already have similar capabilities. As such Comeau C/C++ now
> supports a #warning, and we're considering some of the other things
> too, as an extension. So, your idea is not that far fetched.
It's not my idea actually. I found it in Jeff Richter's book "Advanced
Windows". And looking over that part of the book again, I see that I
incorrectly repeated the form used by MSVC. Richter shows:
#pragma message("Fix this later")
And then he goes on to relate how this message can be made more helpful by
using a macro to insert the file and line number along with the text. I
think I repeated this incorrectly, however, because MSVC uses #pragma
comment quite extensively - for indicating a lib to be statically linked as
well as for setting linker switches
#pragma comment(lib, "libname.lib")
#pragma comment(linker, "/Section:Shared,RWS")
#pragma comment(linker, "/Delay:unload")
and so forth. And since this form is more widely used than 'message' it
stuck in my mind. At any rate, I think this facility would be helpful,
although I don't think it's of primary importance.
Mike
jacob navia
> In article <3d1a1011...@news.t-online.de>,
>
> If the link fails, why should it be any different than any
> other link failure?
Yes. I want to leave the user the possibility of #including some header file
without a fatal error when it just needs some #define or other definition
and not the library itself.
Franz Fritsche
>>
>> I think a _warning_ should be issued!
>>
>> (...)
>>
>>On the other hand, I think there _should_ should be at least some
>>"user-information" (feedback) if something "goes wrong". (But a
>>warning would be enough, I think.)
>
> If the link fails, why should it be any different than any
> other link failure?
>
Well I just checked it with:
#include "C:\standard.h"
#include "C:\tools.h"
Where both paths are wrong.
Lcc-win32 (Wedit) shows in the message window:
lcc: C:\...\main.c:1 Could not find include file "C:\standard.h"
lcc: C:\...\main.c:2 Could not find include file "C:\tools.h"
Warning: C:\...\main.c: 6 missing prototype for printf
...
etc.
So the status of this "messages" is somehow unclear for me (are they
warnings?) this form of _feedback_ would suffice, I think.
And I agree: it needn't to "be any different than any other link
failure" - at least not necessarily. :-)
F.
jacob navia
> Well I just checked it with:
>
> #include "C:\standard.h"
> #include "C:\tools.h"
>
> Where both paths are wrong.
>
> Lcc-win32 (Wedit) shows in the message window:
>
> lcc: C:\...\main.c:1 Could not find include file "C:\standard.h"
> lcc: C:\...\main.c:2 Could not find include file "C:\tools.h"
> Warning: C:\...\main.c: 6 missing prototype for printf
> ...
> etc.
>
> So the status of this "messages" is somehow unclear for me (are they
> warnings?) this form of _feedback_ would suffice, I think.
>
> And I agree: it needn't to "be any different than any other link
> failure" - at least not necessarily. :-)
You are right Franz. Will put a warning out. This could make easier to
understand the following "undefined symbol " message by the way.
warning: could not find <foo.lib>
undefined reference to _foo@8
Looks easy to understand, and the user knows exactly where the problem is.
Franz Fritsche
>
> You are right Franz.
>
Well, its just my opinion. ( Certain thoughts considering the things
you proposed.) - I certainly hope that others (can/may) agree too.
>
> Will put a warning out. This could make easier to
> understand the following "undefined symbol " message
> by the way.
>
> warning: could not find <foo.lib>
> undefined reference to _foo@8
>
> Looks easy to understand, and the user knows exactly
> where the problem is.
>
Looks good (for the moment).
[ Other opinions?! ]
F.
P.S.
Well, I really appreciate your good spirit. And it shows! :-)
Mike Caetano
news:afcuce$ddih1$1...@ID-115446.news.dfncis.de...
> Now, how about [ #pragma comment "fixme!!" ] - to send output to the
> debugging window in similar fashion to #error but without throwing an
error?
Oops! Jacob tells me that lccwin32 implements the #warning construct. I
wasn't able to locate any mention of it in the docs however. At any rate,
that takes care of that.
Mike
Greg Comeau
I wouldn't think that would be a problem. Right, just uttering
the construct is a request not a demand, at least in the case above.
Greg Comeau
jacob navia <ja...@jacob.remcomp.fr> wrote:
>> Well I just checked it with:
>>
>> #include "C:\standard.h"
>> #include "C:\tools.h"
>>
>> Where both paths are wrong.
>>
>> Lcc-win32 (Wedit) shows in the message window:
>>
>> lcc: C:\...\main.c:1 Could not find include file "C:\standard.h"
>> lcc: C:\...\main.c:2 Could not find include file "C:\tools.h"
>> Warning: C:\...\main.c: 6 missing prototype for printf
>> ...
>> etc.
>>
>> So the status of this "messages" is somehow unclear for me (are they
>> warnings?) this form of _feedback_ would suffice, I think.
>>
>> And I agree: it needn't to "be any different than any other link
>> failure" - at least not necessarily. :-)
>
>You are right Franz. Will put a warning out.
At compile time?
>This could make easier to
>understand the following "undefined symbol " message by the way.
>
>warning: could not find <foo.lib>
>undefined reference to _foo@8
>
>Looks easy to understand, and the user knows exactly where the problem is.
It should be turn-off'able too then. As well, some may want an
option to ignore all #pragma lib's.
Johannes Totz
> debugging window in similar fashion to #error but without throwing an
> error?
>:-)
Did you try OutputDebugMessage(...)?
Johannes
Mike Caetano
news:afg5as$nja$1...@graf.cs.uni-magdeburg.de...
> Did you try OutputDebugMessage(...)?
Yes. I tried that. It pops a message box which I don't like. The #warning
directive does exactly what I want. It puts the message into the build
window while allowing the build to succeed. That way a directive such as
"#warning fix me later!" can be ignored while focusing on other parts of the
project. In contrast, constantly dismissing a message box could quickly
become very annoying.
Mike
Johannes Totz
> very annoying.
Yeah :-) I just use it for dll-debugging with DebugView when I don't have
the application src-code, i.e. an ODBC driver with MS Access or Excel.
Johannes
Greg Comeau
Closeyour Hotmailaccount <atomi...@hotmail.com> wrote:
>Oh my gawd!
>Jacob, does this mean I can do this:
>------------------
>#ifndef NDEBUG
>#pragma lib "memman.lib"
>#else
>#pragma lib "memman_d.lib"
>#endif
>------------------
>You just saved me TONS of work!
I think he's saying that it does mean that.
>Also, does this work with lcc and lcclnk, lc, and/or wedit?
I don't know, and I think that's an underlying problem as
I pointed out in some other messages. In particular,
how do you control telling it not to use a lib that
was requested (especially when both are available at link time)?
jacob navia
> I pointed out in some other messages. In particular,
> how do you control telling it not to use a lib that
> was requested (especially when both are available at link time)?
Put the offending #pragma lib in a conditional as:
#ifdef USEOLDLIB
#pragma lib "oldlib.lib"
#else
#pragma lib "newlib.lib"
#endif
or even
#ifndef NOPRAGMALIB
#pragma lib "foo.lib"
#endif