| RE: [cdt-dev] Project model: More questions and some feedback |
|
Hi Sascha, Thanks for the great questions! Please see my comments
embedded below. Mikhail -----Original Message----- Hi, I've got some more questions/suggestions regarding the project model.
Please tell me if I should raise a bug. QUESTIONS: --- What exactly is the difference between setting up source folders
(source locations), source location exclusion filters and excluding resources
from built (resource properties)? [Mikhail] These settings should be consistent with each other, so there
should be no difference between them. Please raise a bug if you see any
inconsistency. Why is it possible to exclude resources from build, which are not
within a source build path ? [Mikhail] Could you create a bug for this, describing steps to
reproduce? --- Let's assume I have a plugin which provides source locations,
include folder and macro settings based on an external file which can be edited
by the user. What would be the best way to let the model know about these settings? Should these settings be added manually by creating CSourceEntry, CIncludePath, CMacroEntry and adding these to the
configuration/resource ? Or is there a way to register some kind of dynamic provider which the
model will ask? [Mikhail] Currently you will have to do it manually, but I guess we
could automate this. There CProjectDescription framework already contains the internal
functionality that allows dynamic adding settings exported by other projects,
and I think it can be easily adopted to what you want, i.e. to something like
the “External SDKs” approach. I’m going to work on debugging/enhancing the project references
mechanism next week and will look into this as well. Could you raise an enhancement request for this? Is there a way to make these settings read-only? Since they are defined
by an external file they should appear on the C/C++ paths and symbols, but
the user should not be able to delete/edit them. I noticed the READONLY
flag for ICSettingEntry, but it does not seem to have any effect. [Mikhail] I’m not sure this is needed. There were complains
already regarding the inability to modify(unset) the “builtin” discovered
settings (i.e. includes and symbols). I think the users should be able to
perform any adjustments they want while being able to restore the default
settings. --- I asked this before so I will make this a short question: When I
add a sub folder like Project\folderA\folderB to the source locations, the
project view will show a folder with the full name "folderA\FolderB".
Is this intended? Or a bug? Will source locations always show up in the root,
even if they are subfolders? Looks kind of weird. [Mikhail] This is the initial behavior that was in CDT before, we did
not change anything regarding this with the New Project Model functionality. I don’t know why the source location folders are displayed in
this way, but the current behavior does not seem user-friendly to me as well. I
think you should raise a bug regarding this. SUGGESTIONS: --- When I exclude a folder from built only this folder does get marked
as "excluded" in the project view but all subfolders and files
are not marked as excluded. I think all children of an excluded folder should be
marked excluded, too. Just like in MSVC :) [Mikhail] Please raise a bug regarding this and we’ll consider
this. --- Adding property pages I noticed there are quite alot of C/C++
property pages like C/C++ Build settings, C/C++ Variables, .... Wouldn't it make sense to group those properties just like Java and PDE do? Like: C/C++ Build
settings Build
Variables ... Or maybe: C/C++ Build Settings Variables C/C++ Preferences Indexer ... [Mikhail] That’s a great point. Could you raise a bug regarding
this so that we could discuss the possible approaches there? In my turn I’ll
think on the best way(s) of grouping settings and post some suggestions there. --- The context menu of the project explorer is quite
long (especially for C/C++ projects). I guess it would make sense to group some C/C++
actions. [Mikhail] Good point as well. Could you raise a bud regarding this? Thanks, Mikhail Mmm, there was more... well, next time :) Thanks in advance Sascha _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev |