Let me know if everything works as it should or if patches need to be adjusted to new changes from upstream
Why not concatenate all patches into one like it is done in HaikuPorts?
Git automatically creates multiple files when running git format-patch.
I guess they could be merged into one file while still keeping it separated into commits,but I didnāt bother to try.
Iām very sorry for going off-topic again,now that the ICU stuff was finally split into itās own topic,but regarding the HaikuPorts patchset stuffā¦
I find it overly complicated to work with it,doing minimal changes and porting it to the next version.
I also regularly contribute to the OpenIndiana package repository and there we have a patches folder for each package and you can put patches for different things in different files which are smaller and easier to maintain.
Patches are generated using GNU diff and applied using GNU patch.
See here for an example: oi-userland/components/web/librewolf at oi/hipster Ā· OpenIndiana/oi-userland Ā· GitHub
(Just to showcase that as example,I donāt want to start a war over the best patch format here)
You can use git format-patch --stdout > patchset.diff
to produce single patchset file. It still preserve individual commits.
From the question āWhy build a new browser in C++ when safer and more modern languages are available?ā:
We are actively evaluating a number of alternatives and will be adding a mature successor language to the project in the near future. This process is already quite far along, and prototypes exist in multiple languages.
Sounds like a massive rewrite may be happening in the future. Depending on what the selected memory-safe language will be, the days of Ladybird on Haiku may be numbered.
I see this new Ladybird more and more critical.
Also,I donāt like those overhyped trend languages.
I donāt say everything should be C++ forever,either,but I donāt see a reason to rewrite perfectly working code in something else.
Sounds like a big waste of time to me.
This wonāt necessarily have to be a problem for Haiku,however,since we can still use the other Ladybird from the SerenityOS project instead.
SerenityOS wonāt go away,it still looks quite active and they require everything written in C++,so theyāll have to maintain their own fork in case the new Ladybird gets rewritten,and we can use that then.
The only downside is that we canāt upstream patches to SerenityOS.
By the way,what is the status of my patches,did you try to get them upstreamed already?
I was about to start testing the patches a couple days ago, then all of these new developments and controversies surrounding Ladybird (and SerenityOS) started occurring. Due to that, Iāve been holding off on anything related to Ladybird until the situation settles down.
P.S.:
This is not an invitation to get into what the aforementioned new developments and controversies around Ladybird and SerenityOS are. We do not need yet another topic with 200+ posts and more moderators resigning. The point is that it is currently a tumultuous time for both projects and it may be better to stay back and wait.
I guess most of the patches wonāt apply cleanly anymore already.
The Ladybird codebase is a fast-moving target so patches have to be upstreamed as fast as possible,or the whole work has to be done again,based on the newer source code.
Besides that,it will be required to test if the patches are still sufficient to get a working browser or additional patches for new code are needed now.
Please,next time tell me when you have time and I can then create up-to-date patches that are upstreamed at best at the same or the next day.
Personally, Iād advise waiting for further news about what programming language the upcoming rewrite will be. May not be worth making patches for a web browser that could become magnitudes more difficult to port the next day, due to the programming language to be used.
Iād suggest the exact opposite: Get the stuff merged before the code becomes totally unreadable for me (depending on what the language will be) and all my efforts are wasted time.
Personally,I donāt have any interest in learning any new language only for porting (and especially not any overhyped modern shit) and will either abandon the port at this point or maintain a own fork of the SerenityOS C++ Ladybird with my Haiku-specific patches.
As long it can run on Qt, GTK or Wayland, it should be still portable to Haiku.
It might just be faster and handier if you upstream the patches yourself.
If youāre committed to this, then get the patches ready soon as I have a window of free time during the weekend.
That would require nipos to be willing to use GitHub and Discord, which heās repeatedly refused to do so.
Thanks,Iāll try to get the patches ready today.
It will take some hours,however,as my Haiku computer isnāt the fastest when it comes to compiling.
Okay,forget about it,Ladybird on Haiku is dead.
They dediced to add even more third-party stuff as dependencies.
The build system complains about missing skia,which we donāt even have in the repository.
And I guess it will only get worse from this point.
I could try building from a recent SerenityOS source and I will likely succeed with that,but considering upstream will reject platform support patches in this repository,thereās no point in doing so.
Edit: Just tried that,just for fun,and it also doesnāt work.
They added some checks that you canāt even attempt to build it outside of the SerenityOS system,and if I comment-out the checks,it fails to find some cmake files.
skia is similar to AGG or Cairo, it is a drawing library. One advantage is that it can allow direct gpu rendering.
Out of curiosity, was there a specific reason to port ladybird and not work on webkit or netsurf? I reckon you could probably improve those ports if you were interested : )
It was just a fun side-project for me.
I saw that there was a completely new web engine and I was interested in playing around with it.
Also,it was really easy to port as long as it primarily used own libraries from the same repository,and their stuff was easily portable and well-written.
So I decided to give it a try and see how it goes.
Iām absolutely not a experienced C++ developer,so I donāt think I can help with Netsurf or WebKit,where Iād have to write new code instead of only getting existing code to work on Haiku.
Iām more a web developer,currently working intensively with the Crystal language for server-side stuff,but also doing things like PHP and Javascript.
Running the build command,reading the error message and trying to get it solved was easy enough for me,but adding new features to a C++ project may not.