"Include Libary" System

Working on new editor enhancements?
User avatar
Rescator
Addict
Addict
Posts: 1769
Joined: Sat Feb 19, 2005 5:05 pm
Location: Norway

"Include Libary" System

Post by Rescator »

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?
jamba
Enthusiast
Enthusiast
Posts: 144
Joined: Fri Jan 15, 2010 2:03 pm
Location: Triad, NC
Contact:

Re: "Include Libary" System

Post by jamba »

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.
-Jon

Fedora user
But I work with Win7
Zach
Addict
Addict
Posts: 1654
Joined: Sun Dec 12, 2010 12:36 am
Location: Somewhere in the midwest
Contact:

Re: "Include Libary" System

Post by Zach »

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.
Image
Post Reply