IDE: Plugin system via PBI files

[Sicro]

Fred has announced that he understandably doesn't have enough time to implement all the functional wishes of PB users.
Wouldn't it be appropriate to integrate a plugin system? The CodeArchive, which I am currently building up with helpers, aims to integrate functions via user codes.

This is how I imagine the plugin system:

• A directory in which PBI (PureBasic Include) files can be stored, which the PB-IDE scans at program startup (recursively at best) and treats the procedures contained in the PBI files as native procedures.
• The plugins should be available as PBI files, because they don't have to be compiled for all operating systems before.

[Dude]

+1, definitely!

I currently do this manually. I have a folder of IncludeFiles and the start of each of my sources has to look similar to the below.

It would be great just to drop them into a folder and not have to manually include or worry about them.

[uwekel]

+1

[davido]

+1

[blueb]

+1

[Sicro]

@Dude:
I just wrote a PB tool that automates including the include files of a directory, see the code below.
However, the auto-completion of the included procedures is still missing and that bothers me the most.

Code: Select all

;   Description: Includes temporarily all include files of a directory into the code before compiling
;            OS: Windows, Linux, Mac
; English-Forum: 
;  French-Forum: 
;  German-Forum: 
; -----------------------------------------------------------------------------

; MIT License
; 
; Copyright (c) 2018 Sicro
; 
; Permission is hereby granted, free of charge, to any person obtaining a copy
; of this software and associated documentation files (the "Software"), to deal
; in the Software without restriction, including without limitation the rights
; to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
; copies of the Software, and to permit persons to whom the Software is
; furnished to do so, subject to the following conditions:
; 
; The above copyright notice and this permission notice shall be included in all
; copies or substantial portions of the Software.
; 
; THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
; IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
; FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
; AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
; LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
; OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
; SOFTWARE.

; Tool Settings:
; - Arguments: "IncludeFilesDirectoryPath" "%COMPILEFILE"
; - Event:     Before Compile/Run
; - Wait until tool quits
; - Hide Tool from the Main menu

CompilerIf #PB_Compiler_OS = #PB_OS_Linux
  ImportC "-no-pie" : EndImport
CompilerEndIf

Procedure ScanDir(Path$, List Files$())
  
  Select Right(Path$, 1)
      
    Case "/", "\"
      
    Default
      CompilerIf #PB_Compiler_OS = #PB_OS_Windows
        Path$ + "\"
      CompilerElse
        Path$ + "/"
      CompilerEndIf
      
  EndSelect
  
  Protected Directory = ExamineDirectory(#PB_Any, Path$, "")
  If Directory = 0 : ProcedureReturn : EndIf
  
  While NextDirectoryEntry(Directory)
    Select DirectoryEntryType(Directory)
        
      Case #PB_DirectoryEntry_File
        If AddElement(Files$())
          Files$() = Path$ + DirectoryEntryName(Directory)
        EndIf
        
      Case #PB_DirectoryEntry_Directory
        Select DirectoryEntryName(Directory)
          Case ".", ".."
          Default
            ScanDir(Path$ + DirectoryEntryName(Directory), Files$())
        EndSelect
        
    EndSelect
  Wend
  
  FinishDirectory(Directory)
  
EndProcedure

Procedure InsertIncludeFilesToCode(CodeFilePath$, List IncludeFiles$())
  
  Protected CodeForIncludeFiles$
  ForEach IncludeFiles$()
    CodeForIncludeFiles$ + ~"IncludeFile \"" + IncludeFiles$() + ~"\"" + #LF$
  Next
  
  Protected CodeFile = OpenFile(#PB_Any, CodeFilePath$)
  If CodeFile = 0 : ProcedureReturn : EndIf
  
  Protected CodeFileStringFormat = ReadStringFormat(CodeFile)
  Protected CodeFileContent$ = ReadString(CodeFile, #PB_File_IgnoreEOL | CodeFileStringFormat)
  
  CodeFileContent$ = CodeForIncludeFiles$ + CodeFileContent$
  
  FileSeek(CodeFile, 0)
  TruncateFile(CodeFile)
  WriteStringFormat(CodeFile, CodeFileStringFormat)
  WriteStringN(CodeFile, CodeFileContent$, CodeFileStringFormat)
  
  CloseFile(CodeFile)
  
EndProcedure

NewList IncludeFiles$()
Define IncludeFilesDirectory$ = ProgramParameter(0)
Define CompileFile$           = ProgramParameter(1)

If IncludeFilesDirectory$ = "" Or CompileFile$ = ""
  MessageRequester("PB-IDE-Tool 'InsertIncludeFiles'", "The tool settings are wrong!", #PB_MessageRequester_Error)
  End
EndIf

Select LCase(GetExtensionPart(CompileFile$))
  Case "pb", "pbi" ; This is needed to ignore the cfg files
    ScanDir(IncludeFilesDirectory$, IncludeFiles$())
    InsertIncludeFilesToCode(CompileFile$, IncludeFiles$())
EndSelect

Edit: Code updated

[Bisonte]

Definitely : +1

[the.weavster]

+1

[IdeasVacuum]

+1
Sounds like a very good idea - possibly needs a PB IDE SDK?

[Mistrel]

I understand why this request was made but all it really does it move the dependency from your project to your IDE environment.

This ends up being worse when it comes to sharing code because your environment may differ from someone else's. At least when it comes to including files within the source code, you can clearly see what file dependencies are missing rather than getting hit with a missing procedure error and not knowing what library it actually belongs to.

For example:

Lets say that your environment knows about "SomeFile.pbi" so you don't have to include it in your source. Then your environment changes, you share you source with someone, or revisit it some time later with a different configuration. Now suddenly you get an error about a missing procedure definition:

Code: Select all

do_thing()

Of course, there is no include anywhere so you have no idea where this function is actually defined since it's part of some environment setting.

If you are having trouble managing source dependencies, the answer isn't to cram everything into the IDE; it's to learn better source control practices.

For my configuration I set a custom constant which points to my source repository:

Code: Select all

CODESPUNK_HOME="C:\development\repositories\libcodespunk"

Then in my source I include a relative path:

Code: Select all

XIncludeFile #CODESPUNK_HOME+"/purebasic/h.SAL.pb"
XIncludeFile #CODESPUNK_HOME+"/purebasic/h.Types.pb"

If for some reason I change the location of my repository then I only need to update the constant and everything else propagates out.

The only problem with this is that if my development environment goes out of sync or if I move to a different machine with a different path then this breaks. I have a feature request to address this issue:

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

In my opinion, the best layout is:

Code: Select all

Environment Variables (variable)
   -> Constants (inherit environment)
      -> Includes (relative to constants)

This allows code to be very portable and easily configurable across different computers, operating systems, and other environments.

[the.weavster]

Perhaps this could also be integrated with an official repository where trusted contributors could upload the most recent version of their include file(s) and the IDE will list what's available and retrieve any the user selects.

[TI-994A]

Perhaps this could also be integrated with an official repository where trusted contributors could upload the most recent version of their include file(s) and the IDE will list what's available and retrieve any the user selects.

This sounds like a very good idea. +1

[walbus]

Well, when you see what problems occur with older sources or DLLs,
it will probably fail because it cannot be guaranteed that codes running with a current PB version will also run with future versions.

[Bisonte]

Well, when you see what problems occur with older sources or DLLs,
it will probably fail because it cannot be guaranteed that codes running with a current PB version will also run with future versions.

It is up to the user which codes and which directories he wants to implement. What is the difference to what the user does now when a new PB version is released?

He must adjust his includes. It would be nothing else.

[walbus]

The user has to adjust his includes, that is correct.
But it is primarily about being able to use includes created by others !
If I only use my own, I don't need a external plugin system