[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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).
Best regard,
Sergei Kovalchuk, NXP
Hello Liviu,
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.
BR,
Sergei.
> 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