| Re: [cdt-dev] Future of Managed Build |
I'm not sure I want to do that. Can we document the future of managed build somewhere else? Op 11/02/2020 om 16:05 schreef Jan Baeyens:
Hi All, I'm really happy to see the interest in this topic keeps going :-)Catching up after a holiday and reading through the thread I'm registering following common understandings: 1:We are using different languages and this makes communication difficult. 2:We are talking at different levels business/architectural/analytical/implementation and this makes communication difficult.3:We are using a mail list and this makes communication difficult.4:We all have very different backgrounds and have different models in our heads and this makes communication difficult.So time to level up :-)Like Jonah proposed I'll try to make a new page at https://wiki.eclipse.org/CDT/designs which should help with 3 and 4The first things I want to add are a problem domain description and a use case diagram. I think these 2 will help tackle the 2 first items and the format should help on the 3th and 4th. Note these are business level (like creating a new toolchain) thingies and are completely implementation agnostic.Question: As I no longer have licences for the tools I used to use and eclipse marketplace returns plenty of UML tools .... any advice on a free and good UML tool?Best regards JantjePS: For some of you "problem domain description" and "use case diagram" may sound really difficult but they are in fact very simple things to get to a common understanding of "what we are talking about" (problem domain) and "what to expect" (use case diagram).PPS I realize I have been adding to the confusion by using "model" instead of "an example of a diagram based on the model"Op 11/02/2020 om 7:24 schreef sergei.kovalchuk@xxxxxxxxxx:Hi All,I support the idea to try to use the modeling frameworks for the management project build. On my life experience in the IDE and Tool productization, the modeling part at a first look is a little bit complex. But as a result, using EMF and Xtext approach allow experts to focus on Project codebase details, instead of "where" and "how" I should it define. In other words, I expect from the "modeling", decrease time on development and maintenance and at the same time some clear and flexible way of definition for builders, toolchains, options etc.BR, Sergei Kovalchuk. On 2020-02-11 08:39, Alexander Fedorov wrote:Hi Marc-André, EMF and Xtext, and Eclipse Platform itself are all to switch from re-inventing the standard existing solution to focusing on domain-specific problems. And the current CDT source base is the perfect illustration of that kind of "re-inventing" - it contains a lot of over-verbose code with wrong usages of the platform, which required enormous effort to be created and wants even more to be supported. Java itself was also good to mention: the idea to isolate memory management released so much energy that it was successful despite the initial performance problems. Generally, the idea to separate expertise is quite effective if we can establish "experience exchange" between different expertise areas. And this is exactly what we are looking for: C/C++ experts can formulate "what" should be done for platform/modeling experts who can find better way "how" to make it happen. The result should be extensible enough: i.e. it should be easy to write a textual configuration file (target definition, toolchain definition, etc.) using simple text editor without any "Java coding" or "Eclipse coding" at all. Regards, AF 11.02.2020 0:39, Marc-Andre Laperle пишет:HI, I haven’t followed all of the details of the thread closely but one thing to consider is the barrier of entry for extenders who want to plug into managed build. Using something like EMF or Xtext is probably more elegant from the point of view of an enthusiast/professional Eclipse developer but most C/C++ developers, embedded developers, etc are already put off by writing Java so I have small concerns adding another layer of abstraction through those framework. In an ideal world, I would be curious to see Managed Build be “modelled" only in pure Java with very small extension points. In any case, I personally won’t need Managed build or have time to contribute to it so all I can contribute is a general feeling towards it :) With this said, I do think EMF and Xtext are cool technologies. Marc-AndréOn Feb 5, 2020, at 9:16 AM, William Riley <william.riley@xxxxxxxxxxx> wrote: I've not had chance to catch up on the whole e-mail thread yet so this might have already been covered. A while ago I made a start on a new managed build system that due to other work commitments I've not yet had chance to start sharing. I was designing that system so the toolchain & project configuration mechanisms were completely separate from the actual build file generation/build engine. Any logic needed to determine how to rebuild on changes was going to be placed in a build engine specific implementation, so if targeting a tool like Ninja which can handle those cases itself there would be no special handling inside the managed build system, it would just be generating the Ninja files. The idea with that to keep the core managed build system as small as possible to make it possible connect with different build tools without running into conflicts with how they handle things. Quick overview of the system I'd started. I’ve got the basics of the configuration files both for build settings & the toolchain definitions working but didn’t yet connect a build fine generator yet. High level requirements: · GUI to allow configuration of build options for a project o Options for both "Tools" & "Toolchains" o String, Enum, Boolean & list types supported o Allow overriding of GUI by toolchain implementers · Support multiple "configurations" for each project using the same or different toolchains · UI should allow multiple configurations to be opened at the same time to allow users to compare configurations · Support for multiple build systems (planned to support Ninja & make) · A settings file which can be safely stored in version control & be easily merged with standard merge tools (unlike the current .cproject where the structure can change without any build options actually being changed) · Users should be able to add custom tools to an existing toolchain within an individual configuration · Mechanism for contributing toolchain converters, which could convert the build options from one toolchain to another. Current working ideas: · Make the options UI an editor rather than a property page, accessible either using real files or virtual nodes in the project explorer · Configuration setting file (XText DSL) containing only the options data, not structural information about the toolchain · Configuration selection though launchbar, select configurations rather than projects. Regards William -----Original Message----- From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Liviu Ionescu Sent: 01 February 2020 19:05 To: CDT General developers list. <cdt-dev@xxxxxxxxxxx> Subject: Re: [cdt-dev] Future of Managed BuildOn 1 Feb 2020, at 18:54, Liviu Ionescu <ilg@xxxxxxxxxx> wrote: ... project configuration.What I poorly tried to explain is that this is a complex subject; some tools (like cMake) try to combine it with the builder; other tools may choose to split some functionality to a separate tool. The configuration step may include one-time pre-build operations (like auto-detecting system capabilities, or choosing one of multiple cross tools for different architectures), but also application options, that can be changed at any moment during the project life time (like thread stack sizes, queue sizes, etc). Changing some of these options are reflected only in the content of some header files included in the build, and the builder should be perfectly able to handle the dependencies, but some changes may be reflected in different files being added to/removed from the build, for example when building a portable project for different platforms/architectures. To be noted that the pre-build system capabilities auto-detecting step (introduced by autotools, and took to the extreme by cMake) is not a mandatory step. The other choice is the npm/xPack philosophy: instead of detecting the existing capabilities and trying to make the best use of them by 'bending' the project after them, it is easier to compose the project from mandatory packages (executables and sources) and have a dependency mechanism bring into the project exactly the needed versions. --- These are generally tricky issues, and the exact demarcation line between tools is hard to draw. In brief, a build system must acknowledge that project configuration should be addressed somehow, either internally or externally. Regards, Liviu _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev [1] Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647 _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-devLinks: ------ [1] https://www.eclipse.org/mailman/listinfo/cdt-dev _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cdt-dev