Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Is there interest in a rewritten managed build?

All

It has been a long time since the last update; but here it is.

What is the bad news:

A) my lathe tried to kill me.(Seriously; I could have been dead by now)

B) I ran into an issue that cots me lots of time and is still not fixed.https://github.com/eclipse-cdt/cdt/issues/356

The good news is:

A) The lathe failed to kill me (Though I accept some people would disagree this being good news; for the progress of AutoBuild it is good news)

B) I did make serious progress.

What is that progress?

If I go back to my original plan

  1. Copy/modified code to get the basic framework to run. (done)
  2. get a functional part working
  3. add runnable tests  (used for regression testing)
  4. cleanup/rewite the functional part.
  5. If parts remaining goto 2

The first thing I notice is that I have hardly done any cleanup. The current code is basically a combination of the old code (both managed build and Sloeber); the old code modified and new code.
I want to add more regression tests before I start the real clean up.

I feel the current state of the code is good enough to start the functional part "Integration of third party providers (using Sloeber as a basis)". As sloeber uses "Exclude resource from build" and issue 356 is a pain (and I'm pretty sure they are related) these will get attention as well.

The functional parts I think that are working (probably lots of bugs but working)

1. Most of the gui (on the project level)
2. 1 method for project creation (both c and c++ natures)
3. Project build
4. Change project type (from static lib->dynamic lib->exe->compound exe)
5. Open/close project (very basic code/testing)
6. Build using make
7. build using internal builder
8. Parallel build (does not work with internal builder)
9. Pre/post build commands
10. Dependency analyses to only build the needed files

I would say at this point following functional parts are still missing

1. Dealing with tool providers
2. Exclude resource from build
3. A nicer new project wizard
4. Include/libraries in settings (or just remove it)
5. Trigger project adaption based on persistency file modification (for instance due to git update)
6. Integration of third party providers (using Sloeber as a basis)

So in conclusion:

Currently Autobuild starts to look and feel like ManagedBuild (need to fix issue 356 )
There have been some delays; due to code issues and personal issues. However I'm still progressing and moving on to third party integration.
I still may make the first longest estimate of 1/1/2024

Jantje


Op 2/02/2023 om 20:41 schreef jan:


Op 1/02/2023 om 10:43 schreef Christian Walther:
Jan Baeyens <jan@xxxxxxxxxx> wrote:
FYI: IMHO this is not Eclipse-internal stuff;  it is all(?) CDT stuff.

When I wrote “Eclipse-internal”, I was counting CDT (including MBS and our own extensions on top of it) as part of Eclipse – as opposed to make and build tools that know nothing about Eclipse and CDT.
ok

I agree there is actual extra functionality in Macro's. But what I do not know is: "how can a user use this extra functionality?". Can you provide a hands-on example of using Macro lists that has real user value?

All I can say is that we are using it, I don’t know if that use adds any value that couldn’t be added otherwise. Our toolchain has tools with list-valued options (resulting in command line options that appear multiple times), and our own code provides the recommended list of values (computed on demand) as a macro. The default value of the option is a reference to that macro, so if the user doesn’t do anything, they get the recommended values. But they have the option of adding more values to the list or removing the macro reference that provides the recommended ones.

plugin.xml:
   <option
         id="ch.indel.idev.toolchain.indelimage.option.inosconfig"
         category="ch.indel.idev.toolchain.indelimage.category.other"
         name="INOS config (-k)"
         valueType="stringList"
         command="-k&quot;${value}&quot;">
      <listOptionValue
            value="${InosConfig}">
      </listOptionValue>
   </option>


(Usually users don’t need to do anything in the “Tool Settings” tab pictured here, all settings are made on a higher level in our own UI. The main requirement isn’t the ability for the user to customize (we could add that on our own layer if needed), but that we can supply option values programmatically, computed on demand at makefile generation (or indexing) time, ideally without being stored in .cproject.)

Thanks for you input. It seems to me this is a very good example of "how can a user use this extra functionality?"

Given your explantation of options I'm currently assuming the listOptionValue is at least partly Macro driven. As the macro provider is not in MBS this can be a very local usage of IMacro functionality in MBS and therefore hard to spot.

I didn't yet get to the options code but now I know I need to be extra careful in regards with macro's when I deal with that code. Thanks. This was the exact info I was looking for. If there are other use cases you can think of please let me know.

PS: It seems like you're doing pretty mutch the same as I do with Sloeber. Extensive usage of environment variables/macros stored outside of the .cproject to control the build from our own UI.


 -Christian


_______________________________________________
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

Back to the top