In addition to everything Jan said below, I want to emphasize that CDT projects may contain other *buildable* resources that CDT knows nothing about. In addition to documentation and tests, CDT projects may contain executable scripts,
non-C source-files built by tools other than gcc, which may indirectly be executed/built *during build* through pre/post-build steps. So, a CDT project is an ecosystem, and CDT must behave as a good citizen and not decorate files/folders which it knows
nothing about.
I would also prefer not to see every inactive build-configuration target folder be decorated with a strikethrough either. That would create unnecessary visual clutter in projects with many build-configurations. I would rather have the
single active build-configuration’s target folder be decorated with the label “ [active]”, to keep the UI clean and self-explanatory. And I think it would be nice to also decorate all build-configuration target folders with a new icon-overlay, to help user
tell these apart from regular folders.
From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx>
On Behalf Of Jan Baeyens
Sent: Friday, October 9, 2020 8:14 AM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] [EXTERNAL] Re: Proposal for cdt resources decoration.
Hi
I didn't really follow this discussion but I am confused and alarmed with your example.
I thought a standard CDT project had the root of the project in "source location".
All files under source location are part of the build unless they are matching a "exclude from build" filters.
The files/folders matching the "exclude from build" filter are grayed out and barred like in your example.
I never played with the source locations but given this proposal I assume that files not on the "source location" are not grayed out and barred.
I then also assume that part of your proposal is (1) to bar out these files and folders "because they are not part of the build" and (2) to "mark the source location" folders
Assuming my assumptions are right:
I like 2
I don't like 1. Because if I had a folder named "documentation", "class views", "scripts", "start here", "debug data".... these would be grayed and barred out. Besides it is a double confirmation as source is only under the 2 marked folders.
If I understand correctly you also want to gray out and bar the "non active configuration build target folders"
I have no objections against that but,
1) I think marking the "build target folders" with a annotation (like you propose in 2 for the "source folders") has more added value.
2) your example of this is not consistent as the right part states Test_Build_1 is active and the left part has Test_Build_2 as active
I hope you are not assuming that the project root will no longer be capable to be the source location. For me that is unacceptable.
I find your example confusing because
1) I would not expect a folder called "project settings" to be a source code folder
2) I would not expect test_build_1 and test_build_2 to be configuration names
3) I don't know what to make of the folder test_123 containing config.c. It doesn't make sense to me so I'm undecided whether it should be grayed out or not.
4) The inconsistency mentioned above
5) It doesn't come as a real life example to me. Here is one of my "big" one man project with all the source in the root
Source root in the project folder
There is only one config (mega)
Libraries/AES/example is excluded by a exclusion rule
test_data contains data to run unit tests
web contains web content for my embedded device
documentation contains documentation stuff
I think you understand I'm not looking forward to having all these folders getting grayed and barred
So my proposal: Annotate the source folders and target folders and gray out the not used target folders.
Best regards
Jantje
Op 9/10/2020 om 10:11 schreef Сергей Ковальчук:
Hello All,
Let me start from the beginning and explain again in detail in order to align all of us.
The current CDT resources model for managed-build project based on sources definition by each build configuration, sources are used by indexer function and build procedure.
Attached picture (right part) describes this behavior.
At same time users might have a lot of build configurations with different sources by each configuration and the project will look a little bit complex and unclear.
My proposal to decorate differently resources that are not related to active build configuration. These resources will not be specified as a source.
The next point is temp build directory in my concept it has the same name as build configuration, because CDT does not have some place for definition for it.
The second proposal is to decorate differently eponymous folders with build configuration which contains build artifacts ( .o, .bin, makefile etc).
We are talking about the same things (non-used resource for build configuration),
The resource that not specified as sources for build configuration is evaluated as excluded and non-used by the active builder.
> On 8 Oct 2020, at 09:27, Сергей Ковальчук <serjiokov@xxxxxxxxx> wrote:
>
> For the managed-build project sources specified for particular build configuration and only defined source will be used.
> That was the main reason to decorate other resources as non-used by the active builder.
I'm a bit confused, initially you were talking about decorating inactive build folders, which was ok, especially for projects with many configurations, now you are talking about decorating all non-source resources? Is this necessary?
Since resources that are used in the build are already decorated with a small C in the top right corner, isn't that enough?
Liviu
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
--
--
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
