Personally I've been slowly building a include library.
I name them such:
"Windows 1.0.pbi" this contains window/gui related procedures for example.
If I add new procedures or improve existing ones but do not change my internal "API" it becomes "Windows 1.1.pbi"
If things are changed such that compatibility is broken it becomes "Windows 2.0.pbi" etc.
These includes are copied from the include library to the projects include folder so each project is "self contained", a benefit if a include jumps from 1.x to 2.s which could break existing code.
Some includes have dependencies on others, like my UUID that takes UUID/GUID strings and turn them into .GUID and vice versa, or create new ones.
Again the version numbering makes sure to avoid breaking code or make it easy to notice.
It would be much better if the PureBasic team enhanced the IDE to have such include maintenance built in.
I know "modules" have been mentioned in the past but maybe a system like this would work better and be more flexible, or a combination of both?
"Include Libary" System
Re: "Include Libary" System
I think that this is probably a good thing, however it seems like it would be a great amount of work on the backend/PureBasic side.
Not only that, but this topic seems to vary a lot between individuals.
I like your idea of organizing the includes, though...I may have to take to a similar system.
Not only that, but this topic seems to vary a lot between individuals.
I like your idea of organizing the includes, though...I may have to take to a similar system.
-
- Addict
- Posts: 1654
- Joined: Sun Dec 12, 2010 12:36 am
- Location: Somewhere in the midwest
- Contact:
Re: "Include Libary" System
I know this thread is kind of old. But I wanted to voice my support for the idea anyhow.
Although on the topic of making a change to an include you use regularly, you don't have to copy it to each project directory, IMHO. Because if you are reversioning anyway, it would be easier to just save it as a brand new file with the version change in the filename. That would at least give you centralized storage, and make it easier to setup a template with a common include path, etc.
It would probably save a little disk space in the long run too. A single directory, with all versions of an include versus copying that include to each and every project you want to use it in, etc.
But I think a "Modules" type management interface would be nice/neat. Something where you can just browse a list of your "modules" and when you select it, it's attached to your project settings file, etc. Whether that be some kind of invisible "include" reference in the project settings file, or an autogenerated include statement placed in your source, or whatever.
Of course then you have to come with a standard format.. Deal with compiled versus source code based stuff.. But it would certainly bring Include AND DLL management under one easier to manage roof. You could even have a PB repository (Like Ruby Gems) which hosts the files, and lets users install on the fly.
I don't know how difficult that would actually be, as it creates all kinds of issues with safe code practices, malicious intent, etc.. But I can't imagine it would be too much of a nightmare.
Although on the topic of making a change to an include you use regularly, you don't have to copy it to each project directory, IMHO. Because if you are reversioning anyway, it would be easier to just save it as a brand new file with the version change in the filename. That would at least give you centralized storage, and make it easier to setup a template with a common include path, etc.
It would probably save a little disk space in the long run too. A single directory, with all versions of an include versus copying that include to each and every project you want to use it in, etc.
But I think a "Modules" type management interface would be nice/neat. Something where you can just browse a list of your "modules" and when you select it, it's attached to your project settings file, etc. Whether that be some kind of invisible "include" reference in the project settings file, or an autogenerated include statement placed in your source, or whatever.
Of course then you have to come with a standard format.. Deal with compiled versus source code based stuff.. But it would certainly bring Include AND DLL management under one easier to manage roof. You could even have a PB repository (Like Ruby Gems) which hosts the files, and lets users install on the fly.
I don't know how difficult that would actually be, as it creates all kinds of issues with safe code practices, malicious intent, etc.. But I can't imagine it would be too much of a nightmare.