Limit as to number of include libraries?

[PhilG57]

I had an included header file not beng found.  So using Tools->Options->Folders->Includes I just kept adding libraries thinking eventually the 'header not found' error message would go away.  I finally would up with 17 include libraries and no luck eliminating the error message.  Since I knew where the missing header file lived, I moved that library to the top of the Tools->Options->Folders->Includes list and viola! the error message is gone.

I can only conclude there is some kind of limit Pelles C v8.00.60 x64 will search looking for included files before silently giving up and issusing an error message.

Is this conclusion true?  What is the limit of include files Pelles C will search?

While I'm here, is this limit also in effect for the "Libraries" list???

Many thanks.

[PhilG57]

Hmm - maybe the limit, if there is one, has to do with the number of files in the libraries rather than the number of libraries???

[frankie]

The problem is not a limit to the number of libraries. If such a limit exist in polink it's due only to memory limits.
The reason is that the order in which libraries are scanned has some importance, because of forward reference. Even if in new linkers the list of symbols are normally read immediately before to start to copy code and data, still something can go wrong especially if the library itself has a problem.
To explain clearly imagine that you have a library lib1 that contains a symbol Func1, and a library lib2 with a symbol Func2. Consider that Func1 call Func2. If the linking order is set as:

• lib1.lib
• lib2.lib

When the linker opens lib1 will copy Func1 that will require Func2 that is unknow in that time. This is a forward reference.
Of course such simple problem can't happen because actual technology take care of forward references, but under some special conditions can happen.

[PhilG57]

Thanks but this is purely a compile time problem.  After kicking out message "C:\Users\admin\aaaa\bbbb\cccc.h: fatal error #1035: Can't find include file <xxx/yyyy.h>." the compiler (maybe the preprocessor?) just up and quits.  I think there is some kind of limit in there but I'm not certain...

[Bitbeisser]

Thanks but this is purely a compile time problem.  After kicking out message "C:\Users\admin\aaaa\bbbb\cccc.h: fatal error #1035: Can't find include file <xxx/yyyy.h>." the compiler (maybe the preprocessor?) just up and quits.  I think there is some kind of limit in there but I'm not certain...

I suspect that you are rather using include files not in the intended way, instead of having separately compiled sources files, for which the include files provide the definition, you are including executable code, possibly even with circular references.

In the largest Pelle's C project that I have myself (an adaptation of the Brandy BASIC interpreter), the project has 25 project specific header files, plus 5 or 6 "standard" library header files. And that works just fine...

Ralf

[PhilG57]

Yes, what you suggest could be true.  Knowing you have successfully handled many include files suggests something is rotten here.

This project with which I playing ("netsurf") has 17 separate .c modules.  Some of these .c modules reference functions contained in library routines, the .h and .c sources for which are contained in other folders.  My 17 'main' .c routines include header files from these library routines.

When I originall received a 'header file not found' message, to solve theproblem, I just added the appropriate directory to my list of includes which might have masked my original problem.  I think I'll go back and try to remove most/all of the includes and see what happens.  Stay tuned.  Many thanks thus far...

[Bitbeisser]

Looking again at the error message you posted about "can't find the include file", it makes me now wonder if this is an issue with the way Pelle thinks projects should be organized. There have been some posts/threads in that regards with different points of view on this issue in the past.
Won't have any time to check into that for a while, maybe on Monday, if that turns out to be a quiet day here due to being a holiday...

Ralf

[PhilG57]

One of the nice things about programming is that you can do things you own way; for better or worse...  I don't know how Pelle and others think projects should be organized but here is what I do:

1. Source, header, and resource files comprising a single program should be one project.  Much/most of the code would be here including winmain, callback routines, 'about', menus, dialogues, file manipulation, and initialization code.
2. Other programs called, or linked to, should be in another project.  Routines to access/manipulate a database, for example, would be a separate project.  Static libraries would be a separate project.
3. All projects captured under a separate workspace.  During early work the projects are worked on individually; later the projects are tied together through dependencies set in the workspace.

So I wind up with all the code in a single workspace with projects separated out for clarity and ease of work.

Is this typical???  Thanks.