It would be nice, if when working on a "workspace" with multiple "projects", various options of the project (compiler level, flags, libraries, link options for libraries, etc.), could be inherited from the workspace. Those project options inherited from the workspace would all be the same for each individual project, while projects needing unique options would specify those in the project's .ppj or whatever file. Thanks.
While that's an interesting idea, I guess it better to keep simple the project manager of Pelles C.
Might be possible with Add-In.
Hopefully someone understand a you ideas for it.
Quote from: PhilG57 on March 22, 2026, 04:21:39 PMIt would be nice, if when working on a "workspace" with multiple "projects", various options of the project (compiler level, flags, libraries, link options for libraries, etc.), could be inherited from the workspace. Those project options inherited from the workspace would all be the same for each individual project, while projects needing unique options would specify those in the project's .ppj or whatever file. Thanks.
Not that familiar with the 'workspace' use but I created one with two projects. The workspace file contains none of the project options (from either project) so I can't see how anything would inherit something not existing. Seems this concept it would totally change the way projects themselves and workspaces work.
Alternatively it might be possible to have an Add-In that can select a project mode from one project and replicate it into a different project. This would work similarly to the new Copy Mode feature, except copy from another project rather than copy from an existing mode within the current project.
John Z
Yes, I understand. The .ppw file contains the names of its projects (.ppj files), and any dependency an individual project might have on another project. More stuff might appear in the .ppw file but this is all I've seen so far.
I guess I was hoping the a new "workspace" section in the .ppw file might contain any compiler/linker/etc 'global' values available to an individual project. For example, if you have several projects in a workspace and wish to move all the projects from C11 to C17, an appropriate .ppw entry would reflect that desire. Then each project specifying 'inherit' in the appropriate compiler section entry, would gracefully change to C17. A project with a particular requirement for a different compiler, would just specify that value in the appropriate .ppj compiler entry and inheritance would not take place.
Not a trivial request I know, but a way of embracing large, multi project, projects. As always, thanks.
Just a few notes:
1) Workspace files was added long after project files, limiting the available options.
2) All 169 (currently) sub-projects of Pelles C is in the same workspace file. Not the biggest project in the world, but not "small". Once all the projects are set up, it's mostly a matter of switching between "Debug" and "Release" builds, which is already available for a workspace.
As always, I guess it boils down to what you are used to and what you expect...
Hi. Then how do you compile and test new versions of your code? Would it not be convenient if you could easily switch from C11 to C17 to C?? for all 169 projects as you develop and test new versions?
I am *very* appreciative of your efforts and do not wish to be seen as argumentive so I'll leave this suggestion alone. Many thanks.
I only change the version to upgrade, to a newer version with a feature I must have. This hardly ever happens. Last time was with C11, which introduced atomic types. A handful of projects was improved by this.
Probably more useful in the past, but staying with an older C version may help porting to a different platform. At least no reason to upgrade "just because". Much of recent C enhancements have been cosmetic.