Code::Blocks Forums

Hi,
today i pushed (r13191) a UI for project globs aka automatic source directories.
This adds
+ an UI for the user to easy enter directories and specify if they should be added recursively and with file masks (found under the menu Project->Automatic source paths)
+ a logic based on wxFileSystemWatcher that watches the above added directories for file changes and adds and removes the file as they are added and removed from the file system
+ a rudimentary script binding

BEWARE: this changes behaviour of old file globs, that was only accessible when editing the project file directly.
The old implementation (loading the directories only on project load, and not adding them in the project file directly) made problems with code completion and compiler settings ecc...
I think this implementation is a lot better, but it changes the project file every time a file is added in the directory (as a makefile would).

i worked for this a while ago, obfuscated made some reviews and was ok with it, but because the wxFileSystemWatcher was not available on all platforms in wx2.8 this work was lost. Now that we are on wx3.0 a was thinking to add this to trunk.
Any comments are welcome.
thank you!

I get this warnings/errors when trying to compile in MSW-32 bits:

projectfile.h||In constructor 'ProjectFile::ProjectFile(cbProject*)':|
projectfile.h|237|warning: 'ProjectFile::project' will be initialized after [-Wreorder]|
projectfile.h|195|warning:   'GlobId ProjectFile::globId' [-Wreorder]|
projectfile.cpp|26|warning:   when initialized here [-Wreorder]|

projectmanagerui.o||In function `ZN16ProjectManagerUI13OnManageGlobsER14wxCommandEvent':|
C:\Codeblocks\src\src\projectmanagerui.cpp|1657|undefined reference to `ManageGlobsDlg::ManageGlobsDlg(cbProject*, wxWindow*, int, wxPoint const&, wxSize const&)'|
C:\Codeblocks\src\src\projectmanagerui.cpp|1657|undefined reference to `ManageGlobsDlg::~ManageGlobsDlg()'|
C:\Codeblocks\src\src\projectmanagerui.cpp|1657|undefined reference to `ManageGlobsDlg::~ManageGlobsDlg()'|

The undefined references appear because you added the new files to all projects but CodeBlocks_wx32.cbp. I have attached a patch for this part.

Thank you! Fixed in trunk

I tried to understand how this "globs" work, how I could eventually use them, and how I can translate the few items.
Until now, no real success.
Could you give us some examples or better add them and a detailed description in the CB wiki (Then, I will be able to add this in the documentation).

Quick and dirty wiki article...
i do not know how to describe it better:
https://wiki.codeblocks.org/index.php/Automatic_source_paths

Thanks. It's more clear.
I still have a problem to find an equivallent word for "glob" in french. I don't think that "global' is good. If somebody has an idea ... You can set a translation directly in lauchpad.

I think we should remove the word "glob" from the user perspective... I think "automatic source folder" is a better (but no perfect) naming for user. Glob is only used internally, because of historic reasons....

Quote from: BlueHazzard on February 12, 2023, 08:11:35 PM
My point of view is, that the project file is like a make file. You have to modify a makefile if you add source files to be able to build it.
If you do not add them to the project we have some problems:
1) you can not modify properties of them: Only build with certain build targets ecc.
2) I had other problems with the old implementation, i can not remember any more exactly (it is a 3 years), i think code completion did not work correctly...

We have discussed this with the problems of the original implementation here: http://forums.next.codeblocks.org/index.php/topic,22783.msg154862/topicseen.html

My opinion on this: This feature was never/seldom used by user before, because it had no ui/documentation. So the risk of breaking some project files is minimal. I also pointed this out in the announcement post (https://forums.next.codeblocks.org/index.php/topic,25276.0.html). Now it has UI and documentation and we can expect it to be used... I for example need it for an upcoming plugin i currently am working on...
If you are absolutely against this implementation i can try to look into it and add some flag for old and new behavior?

I will look into the problems with the ids. Thank you for testing and pointing it out.

When I created this feature, long time ago, the intention is to mimic the glob feature of cmake. We have been relying on this feature extensively, and indeed it is not documented, since one needs to know how to use it, it has limitations, eg when new file is added, one needs to reload the project  to pick up the new files. Code completion works, but not always, but with the old code completion plug-in it also worked like this, sometimes yes, sometimes no, but I can indeed think with this glob it is a bit worse.


Now that said, the cmake world is also no longer in favor of their glob feature (it also has some problems), and want sources to be explicitly added. Which we could translate to CB as :

• we also don't want this feature
• we remove both new and old behavior
• we keep the old behavior as is for backwards compatibility

I do think we need to keep the old behavior for backwards compatibility, since it was there to mimic cmake glob (and then you also did not have to touch the CMakeLists.txt anymore), this needs to be re-instated, because overhere everything is now collapsing.

So please provide the old way, and when the new way is wanted, have CB add per directory an extra flag to say new behavior (old behavior should need no changes to be made by the user), absence of this flag means old behavior.

any fixes coming up ?

I also note other strange behaviors, not sure due to this topic, but when I save files that were adjusted, they save and then they auto close.

I work on it. The earliest i can do is this weekend...

Is it also not desired, that the globs get automatically reloaded when new files are added in the directory? So no automatic reloading?

Quote from: BlueHazzard on February 15, 2023, 11:21:25 AM
Is it also not desired, that the globs get automatically reloaded when new files are added in the directory? So no automatic reloading?

I think this would be a very welcome addition.

After commiting this feature files can't be removed from projects (I am not using globs). See this forum thread (https://forums.next.codeblocks.org/index.php/topic,25283.msg172378/topicseen.html?PHPSESSID=bae89f0a4c58990d6745f510a1b03c24#msg172378).

QuoteAfter commiting this feature files can't be removed from projects (I am not using globs). See this forum thread.

fixed in trunk

I have a working test here: https://github.com/bluehazzard/codeblocks_sf/tree/fix/globs/fix_not_add_to_prj/1

@killerbot: can you test it?

Be aware:
*) I found out, that i have to add some option to add globs only to certain targets, so first work for this is in this commit also, but not functional at the moment.
*) I have not looked at the Ids yet.
*) I have added a checkbox  "Add to project" in the globs settings. This naming is not right and i will rename it in "Add files to project file". If you create a new glob this will be set by default. If you load a glob from a project file with this option not present it will be deactivated.

More work on the weekend...


[Edit:] I also saw that the comments in project file are not right...

I tried a build I made from your repo, and I can confirm my project files remain unaltered  :)

please activate this on trunk if you can, since your repo/clone does not contain clangd client, which means many functionality is gone.

Quotesince your repo/clone does not contain clangd client

i do not understand? This is in the git repo, i use it all the time...

Quoteplease activate this on trunk if you can

is in trunk, with many other fixes...

I just switched back to trunk, so no longer from your repo, and the behavior of modified cbp files is back.
And clangd client completion is back.

The diff is due to the following options being saved in the cbp file:
* addToProject=0
* id = some magic value
* wildcard now after the recursive


If this is stable, then I could indeed do a one time commit of all my changed project files ...


UPDATE :
when opening the project file once more, and closing it, CB again says there are changes, I select yes to save them once more, diffing the outcome ==> no change

So when opening my workspace and closing it I have to click 200 times :-(
Please fix this part , since this is rather troublesome

QuoteThe diff is due to the following options being saved in the cbp file:
* addToProject=0
* id = some magic value
* wildcard now after the recursive

I do not see any "easy" possibility to not add this to the project glob project file entry, and keep the features. I would have to store if this were in the origin project file and save only if there. But this would make the code a lot more complicated and not really dev friendly...

Quotewhen opening the project file once more, and closing it, CB again says there are changes,

Can you try my last changes? If they do not fix it, can you give me a minimal example project, i can not reproduce it with my test cases...

[edit:] And thank you a lot for testing!

still the same, will provide a small project later today

attached a little project
open it up in CB, allow it to save the adjusted project file (make a cop of it)
open it up again, once it still thinks there are changes, allow it to save, compare to the copy ==> identical
==> this repeats forever

Thank you a lot!
I think my last commit fixes the error.

Confirmed, and it doesn't even try to add the id field, and switch the order.
So it nicely keeps old style projects untouched :-)

many thanks.

I spotted another regression, when a workspace is opened which contains several projects (say all glob ones, in my case), only the active project has been "scanned", all the other projects have no sources (in the project tree view they also don't have the expand indicator), once you activate the project manually, they get populated.
As such CB is completely useless for such workspace, because trying to build the workspace or a project that has one of those unpopulated ones as dependencies leads to nothing.

Could this be fixed urgently ?

I can reproduce it, at the moment i have no idea why and i will look into it.
But it can take until weekend....

Ok, i think i fixed it in trunk. This should emulate the old behaviour. On loading the workspace all globs get updated. After loading workspace Globs get only updated if you
a) activate the project
b) reload the project

The question is if it would be better to activate file system watches for all projects (also inactive, but this would probably impact performance) or to update globs before building, what also would impact the build performance... Any suggestion?

I can confirm it is fixed. Many thanks.

could you please fix the problem which I think is a result of the adjusted glob, when I have such a project open, and I edit a file, and I safe that file (or by compiling it autosaves), it always closes.
I mentioned this problem before  I think, but I had to upgrade now also CB on my main system, and the annoyance is now so big I can no longer use CB in production (before it was on my secondary system which I don't use that much, so I tried to live with it there).

I never encountered this problem.
I reckon your code generation deletes the files and regenerates them instead of overwriting?
I will try to reproduce and find a fix....

there is no code generation.
The files are there, the project is open, a file is open in the editor pane, edit in the file, save --> editor gets closed.

QuoteThe files are there, the project is open, a file is open in the editor pane, edit in the file, save --> editor gets closed.

I can not reproduce this...
I have also tried to switch save strategy with no difference
What operating system?


Only as i thought when the file gets deleted and regenerated.

Can you share a example project?

Can you test this patch?
I still need some more testing, but it is a start...

on my first test example, which had 100% reproducibility this works ok now :-)

It would still be interesting to know why your system does this...

indeed I also haven't found a real explanation for this. And sometimes it does not happen ..

Can you commit the patch ?

There is still a issue with the fortran plugin i have to fix first...

Can you test this second patch? Specially code completion and so on...
Also it would be interesting, if you could test if you specifically remove the link project file tick in file->properties->build and if this still is persisted in your case
I think this would not work, and i do not think there is a solution for this...
Are you using windows? Are you using some sync application on the source files?

this patch replace the previous one, or is top of the previous one.

One thing I have noticed, that after a compile, or other actions, CB crashed a a lot since I applied the first patch.
Will inspect next time the crash xml.

Instead of the first one...

QuoteOne thing I have noticed, that after a compile, or other actions, CB crashed a a lot since I applied the first patch.

yea, this are my worries.... The problem is i can not test this as elaborate as you, because i can not reproduce... If you could attach a debugger or a trace it would be nice. I suspect the code completion plugin? Can you try to disable it and see if the crashes repeat?

Any updates?

Quote from: BlueHazzard on February 11, 2023, 09:31:37 PM
Quick and dirty wiki article...
i do not know how to describe it better:
https://wiki.codeblocks.org/index.php/Automatic_source_paths

I'm trying to find the 'Automatic source paths...' option. When I don't see it and I'm running the latest binairy release (20.03 windows) version, is this a bug or do I need to install something?

With kind regards


Ludo

This was added after 20.03; You will find it in a recent nightly or in the upcoming release.