Added .gitignore Template for PureBASIC

[Tristano]

A while ago I created a .gitignore template for PureBASIC project and made a pull request on the gitignore project:

https://github.com/github/gitignore/pul ... -289248081

Today it has been integrated into the www.gitignore.io website:

https://www.gitignore.io/api/purebasic

This is the ignore liste I created for PB project:

Code: Select all

### PureBasic ###
# PureBasic

# Settings files
*.pb.cfg
*.pbi.cfg
project.cfg

# Shared libraries
*.so
*.dylib
*.dll

# Binary executables
*.exe
*.app

# End of https://www.gitignore.io/api/purebasic

I'm not sure if it covers all file types for Linux and Mac, so if anyone has suggestion regarding patterns to add I'll modify the list.

[Sicro]

I did not even know that there is a project that provides predefined entries for gitignore. But I've never looked for something like this.
Very useful.

# Settings files
*.pb.cfg
*.pbi.cfg
project.cfg

These files I find important and should not be ignored.
For example, ignoring the files can cause problems when code must be compiled with EnableThreadSafe.

[Tristano]

thanx for the feedback @Sicro

These files I find important and should not be ignored.
For example, ignoring the files can cause problems when code must be compiled with EnableThreadSafe.

I wasnt' aware of this issue regarding threads.

The rationale for including these config files in the exclusion list is that when versioning a PB project with Git, PureBASIC IDE should be set to "Save Settings to: A common file project .cfg for every directory" or to "The file <filename>.pb.cfg" (or to "none"). If set to "The end of the source file" then the source file will always change because of cursor position saving, marker position, etc, leading to Git seeing a file change and requiring spurious commits.

Even with the IDE set to save the cgf info in separate files, these cfg files will change often and if not ignored they become an impedment when swtiching branches (you'll need to either commit them, stash them or discard them). And if different contributors are using different settings, merging the various configurations into each other will create chaos (and an endless list of commits).

I though that since they are created for each user they shouldn't really be shared, and that PureBASIC should handle by itself corrections to these files when a new version of the source is pulled/merged in, correcting any references no longer valid. Usually, when I move source files to another folder (leaving behind the folder-based cfg file) I don't experienc problems: PB just recreates it. But I might be missing some specific cases here, like the EnableThreadSafe you mentioned.

Could you give more details on how the problems might manifest? and which entries in the cfg section are crucial to preserve?

Since the idea of using .gitignore template is to save typing long lists of file patterns, instead of deleting these entries the solution could be to comment them out and let the user decide if he needs them and uncomment these lines. Or, if the cases when ignoring them is problematic are not so common, the user could comment them out on a per project bases. So it dependes on which case is the most common --- so far I didn't experience any problems by ignoring them, because PB IDE recreated them on the other end without problems.

Also, let's say the user has set the IDE to "Save Settings to: The file <filename>.pb.cfg", in this case the lines:

Code: Select all

*.pb.cfg
*.pbi.cfg

are the general rule, and for specific files which might need tracking their .cfg file the user could add a negation to preserve them:

Code: Select all

*.pb.cfg
*.pbi.cfg
# exclusion exceptions:
!somefile.cfg

Which approach you think would be better?

[Sicro]

If set to "The end of the source file" then the source file will always change because of cursor position saving, marker position, etc, leading to Git seeing a file change and requiring spurious commits.

Yes, I know about this problem.

Could you give more details on how the problems might manifest? and which entries in the cfg section are crucial to preserve?

For example, you have a code that needs EnableThreadSafe and you have set it in your settings. Your teammate get this code without your setting "EnableThreadSafe" and on running the code, he gets errors or the code works not correct. On older PB versions is the same problem with ascii/unicode mode.
However, the problem can be circumvented by inserting a check in the code instead of sharing settings:

Code: Select all

CompilerIf #PB_Compiler_Thread
  CompilerError "This code works only with thread-safe enabled!"
CompilerEndIf

Since the idea of using .gitignore template is to save typing long lists of file patterns, instead of deleting these entries the solution could be to comment them out and let the user decide if he needs them and uncomment these lines. Or, if the cases when ignoring them is problematic are not so common, the user could comment them out on a per project bases.

Yes, the gitignore template is only a template and can modified until it fits the user needs. All good.

Now, we have a another problem:

Code: Select all

EnableCompileCount = 12
EnableBuildCount = 2
Constant = CustomConstant_IsDemoMode=1

and the version information settings.
These settings are also lost.

But the problems can't be solved via modifing the gitignore template.

There are solutions for the problems the programmer must do it self:

• Only the project leader has the complete settings file and only he do the final compiling
• The programmer create a program that removes problematic settings from the codes or code setting files before he commit his changes

[Tristano]

Right, I understand what you mean now. I believe that these settings you are referring to would also be saved in the project *.pbp, and that the values in the *pbp file would be given priority for all files included as part of the project. I've checked some project files, and the release version info was there.

Somehow I was giving for granted that any project published on a collaborative platform would be in the form a PB project... which brings some other problems (personal data like working path and PC's username being saved in a shared file), plus some timestamps and version info which will necessarily introduce useless commits.

I have given thoughts to the issue and considered to create a custom tool that would create an manage a different system for handling PureBASIC project, with version control in mind. But I didn't have the time to implement it... From the little research I've done so far, it would have to keep track of the default PB project file and create/update from it the required info. It should also create a project settings file that is truly cross-platform (without "\" and "/" conflicts in paths between Linux and Windows, for example).

Also, I would like to implement some additional information for projects — eg: on which platform it can be compiled, on which architectures, minimum (or maximum) version of PB required. It shouldn't be to hard, but it takes time, and I wouldn't have a Mac to test it on.

Currently, the way I handle *.pbp project files is to remove any entries which are specific to my machine (username, absolute path, file revision, ecc.). On the receiving end, PB IDE will still open the project and fill in the missing parts. The only annoyance is that Git complain that there is an unstaged modified file every time PB IDE saves.