PureBasic Forums - English

Hello All,

A feature I would love to see implemented is the ability to specify global additional search directories for Include Files...

Why?

With a lot of contributions being made in the form of Include Files, it's quite a pain to have to copy and paste them from a central location to the projects directory... Or if you IncludePath "C:/Wherever/" it reduces the portability of the code.

With this feature, each programmer can create a code base full of libraries written by others, such as GoScintilla, at a desired location (not the typical #PB_Compiler_Home + "/include" for instance) and the code they write will be easier to distribute.

As for the argument, what if you have "Object.pbi" in your project root AND in the code base, I would say be more disciplined on how you name your distributed include files, and if necessary, use subfolders such as "framework/object.pbi".

This would be a huge advantage I believe.

Thanks

Probably it's my fault but I don't understand your request.
Suppose you put all your includes under:

"D:\Work\PureBasic\includes\" (like I do)

Every include lib has its own dir under that and every include file there refer to other include files in a hierarchical way using relative paths

IncludeFile #PB_Compiler_FilePath + "name.pbi"

or

IncludeFile #PB_Compiler_FilePath + "..\otherlibname\name.pbi"

so the whole structure can be moved without requiring changes, and you don't need to copy a specific dir in your project dir.

Then the problem...is... where ? Sorry if I'm slow.

Psuedo-Example:

I write a library of code that does something.. but to do that something, I need to have GoScintilla included in my code.

I can put; And yeah, it'll work for me...

If I send it to you, you have to go in and manually change any IncludePath's, thus rendering the code modified.. And you would have to continue modifying my code everytime I release a new revision or update.


If you could just specify in the Editor that you want the compiler to search "D:\Work\PureBasic\includes\" and have GoScintilla already in there, and my code didn't have the IncludePath statements, then all you have to do is drop my code into your 'includes' folder, and no matter what project you make, you can reference my code, and my code will reference GoScintilla without any issues.

For those with Visual Studio, i'm sure you understand what I mean, and how much easier VS handles Additional Include Directories.

I understand.

In your case I would say you should redistribute "GoScintilla.pbi" with your code because there is no guarantee I have the exact same version you have or I could have modified it slightly (after all is source code).

But in any case, or if you can't for some reason, that's what I would do:

and if the third party include is not written to behave as it should using relative paths:
You have only a constant to modify and you are set.

Actually I have #ROOT$ defined as a resident in my system for just this reason. But I have nothing against you request, it's only I use this system and it's ok with me.

And what if (for example) GoScintilla has a memory leak in one of it's procedures... The author fixes this leak without modifying the Procedure names, or functionality... Rather than just you downloading a new version, placing it into your code base, it would also be my responsibility to update my distribution containing the new, bug-fixed version.

Also, not every author would be happy about me including their source code in my distribution. Especially if a restrictive license is applied to the work.
...

Now, the framework which I am currently working on may contain up to 50+ include files, that'll be contained within a subdirectory... There will be a lot of updates to it, which will not affect the currently existing files (unless for bug-fixes), and users may not want to have to go through the work of copying the new files to every project they are referencing it in.

Users also may not want to go into the source code and change any references to include files/include paths/constants to make sure it all works.

...

Having additional search paths is a tried and tested method which is successful (hence Visual Studio), and the feature would be very useful to those who would want to take advantage of it. You may want to use 'work arounds', but I would personally like the option.

Thanks

Env wrote:And what if (for example) GoScintilla has a memory leak in one of it's procedures... The author fixes this leak without modifying the Procedure names, or functionality... Rather than just you downloading a new version, placing it into your code base, it would also be my responsibility to update my distribution containing the new, bug-fixed version.

Yes, that's one of the options. The one guaranteeing your code will work as it supposed to do (because you checked it).
The other one is to left anyone to do to as he please and hope all works well, if they have still access to the same include you are using, and without unexpected side effects.

Env wrote: Also, not every author would be happy about me including their source code in my distribution. Especially if a restrictive license is applied to the work.

That's why I said: "But in any case, or if you can't for some reason ...".
In that case there is no way out.

Env wrote: Now, the framework which I am currently working on may contain up to 50+ include files, that'll be contained within a subdirectory... There will be a lot of updates to it, which will not affect the currently existing files (unless for bug-fixes), and users may not want to have to go through the work of copying the new files to every project they are referencing it in.

I'm doing the same. I don't see the need to duplicate that for every user-project, as I said.
But now I understand you are talking about the need of distributing something not self-contained, possibly needing more than one third-party include and every single one of these can be anywhere on the target disk.
In that case, MULTIPLE different search paths can be useful if you don't have a single, master, root directory under which you keep all your includes (and your project).

Env wrote: Having additional search paths is a tried and tested method which is successful (hence Visual Studio), and the feature would be very useful to those who would want to take advantage of it. You may want to use 'work arounds', but I would personally like the option.

In my case is not a workaround and works well, but in your case it's not applicable. That kind of "sparse" structure is something I try to avoid but I have nothing against your request.

See here for an alternative:

http://www.purebasic.fr/english/viewtop ... =3&t=43921

See here for caveat and suggested fix (posted to bug reports over a year ago)

http://www.purebasic.fr/english/viewtop ... =4&t=44177