Conversation
|
Thanks for the PR and sorry for the late reply. Even if I hate autotools with all my heart, they are capable of producing a unreadable but dependency-free configure script that can run in (almost?) any POSIX-compliant machine, including very old ones. There are other issues with autotools too, which are mostly the reason I'll probably change the build system in the future, but I don't like the idea of adding python as a build dependency because of meson (or using the WIP muon). As FLTK has switched recently to cmake, and it is very likely that it has to be supported in every platform that we want to build Dillo on, we can asume that cmake is already available due to indirect build dependencies. So I will be inclined to choose it over meson, which should yield similar speeds when using ninja instead of make. In any case, I won't take this decision without making a study beforehand of the options, and see which one is more appropriate. Also consider the fact that I have already some knowledge on cmake, and almost none on meson. Regardless, this change will cause a major version bump, so it will not likely happen soon. Regarding the |
Having recently done the fvwm3 meson port where Muon was a desired feature, I can say that the recent
CMake is "fine" however IMO Meson results in far more maintainable and readable build system code, and typically one obvious way to accomplish any given task rather than the ~5 ways that there are to do it in CMake (with no indication which is more appropriate for a given situation). Which platforms that we're building C++11 code on don't support C99 and/or Python anyway ;) With 99% of the porting done you shouldn't need to dig into the guts for quite a while. I may submit a patch for the |
I need to understand very deeply the build system as to debug weird problems in all kinds of platforms I don't have access to, other than a mail/IRC channel with the person. So, totally the opposite.
Thanks, that would be nice. |
|
Following up on this, it looks like it's (almost) all working:
Not sure why the PNG isn't visible but that should be straightforward to fix, and the |
Kangie
force-pushed
the
a-proper-build-system
branch
from
8ad51db to
524c8cd
Compare
|
OK, making progress... I had HAVE_PNG not ENABLE_PNG. This is looking good:
|
|
Sorry about the spam, but best to keep this commentary separate:
There's little reason (aside from keeping autotools in the repo...) not to include the meson build files alongside autotools for a transitional period, then you are able to deprecate autotools and remove it at a time of your choosing with the confidence that it's not going to suddenly cause downstream issues. |
Kangie
force-pushed
the
a-proper-build-system
branch
22 times, most recently
from
62e57c9 to
219fd24
Compare
Making the world a better place is its own reward. Additionally, as a downstream packager/maintainer it ended up being more effective to rewrite the whole build system than deal with the mess that is the existing autotools impl. I also really don't want to deal with more downstream tickets or additional porting work due to the (at best, charitably described as) legacy way in which the current Autotools implementation does things.
I would be more inclined to help if I didn't have to deal with a poor autotools impl, and I'm not inclined to fix autotools when the work on meson is already done.
As the current maintainer of Dillo, that's your prerogative. I can point at other examples where projects aimed at low spec / older machines and which value portability have gone with precisely this approach, and picked Meson.
As a C++ project you can assume that C99 compilers will be available to provide If your platforms need C++11 and don't support C99 that is, honestly, their problem. Users can always continue to use an older tarball - who actually updates these legacy systems you're concerned about frequently, and isn't likely to just grab an older tarball?
The TL;DR is that I've already done all of the work for you on each of the issues that you've just listed. If you want to throw that away because you already have "some knowledge" of cmake that is, of course, your choice. Having already admitted that you already have limited time to work on this project, and with volunteers submitting fixes for deficiencies in the existing build system that you are aware of, it really seems like you're shooting yourself in the foot by not considering this.
Saving time in CI/downstream delivers on measurable benefits to both energy consumption and to the people that have to actually verify their own bulids. Additionally the reduced complexity of Meson (and the use of a matrix to provide better CI/CD coverage in a concise manner) lends itself to a more maintainable build system going forward. How many autotools issues have not been fixed because it's terrible spaghetti that's too hard to parse?
Conveniently I, as a downstream packager, do want to know that my package behaves as expected before pushing it out to my users.
I'm really not inclined to touch anything to do with autotools in my limited time for this project. |
This is far from the reality. You have done a fair amount of work to help yourself avoid dealing with autotools (which is understandable) but you have not really considered the implications of this change for the project and other users. The expensive part of the work is not porting this to a new build system, but maintaining it over the years and identifying issues reported by users from other platforms I don't have access to. You have continued to work on this on your own, even if I have already explained to you that I will evaluate this in the future not now. I cannot stop you from spending your own time into whatever it is you what to spend it. Your current solution continues to rely on the https://cmake.org/cmake/help/latest/module/FindFLTK.html
The hostile behavior is not helping. I suggest you consider how you what to approach the FOSS comunity.
And I, as the person who wrote the test infrastructure as well as those tests, I'm telling you that they are not designed for you to run as packager. They are designed to avoid introducing regressions in the layout engine. Same with RTFL, which I have no idea why you enabled it under the "debug" flag. If you still insist into running them, I recommend you read the output logs to see what is wrong rather than blaming autotools: https://933451.bugs.gentoo.org/attachment.cgi?id=894972 Your convert(1) program doesn't understand I really don't have any interest in pursuing this discussion futher, as I want to focus on the next 3.2.0 release. I understand your position, and I will come back to reevaluate this in the future, hopefully when we have some more exotic machines to test a build system on. |
You need a working (or mostly-working) PR to evaluate; the initial state was 'it builds'. The current PR is mostly feature-complete, however obviously the HTML tests aren't running properly in CI (likely down to how the script is invoked via meson), and some of the more debug-y options are not yet implemented ( edit: HTML tests actually appear to be working locally, but never returning properly - the test output appears to show expected tests and failures but Meson's test harness isn't happy and if the timeout is disabled the tests "run" indefinitely - I'll look into the test script at some point, maybe. Edit 2: First HTML test terminated successfully without intervention in just over an hour so they will eventually complete. Edit 3: After remembering to install Dillo into a prefix I'm able to successfully run the HTML rendering tests via meson (using the binary in
Thanks for the pointer, I'd assumed that was coming with upstream's port to CMake that you mentioned; I've pushed a commit that will use this to detect FLTK (which I'll rebase and squash at some point soon); turns out it needed
I'm sorry that you feel that this is hostile, there has been some miscommunication; It's your project, it's your choice whether or not you accept offered help - I'm not going to be bitter if you go with CMake (though if you hit the '5 ways to do something with no obvious best option' I may drop-in for an 'I told you so'). On my part I'm a bit of a build system buff who has worked on / ported multiple projects, and I have seen many poor CMake implementations in-the-wild: I regularly work on Autotools, CMake, GN, Meson, and hand-rolled scientific computing Makefiles. I'm also involved in upstream fixes to many packages that I maintain; I'd consider your examples to be 'direct' or 'blunt' communication but I'll take it under consideration. I'm not likely to submit additional PRs for the trivial fixes, please feel free to cherry pick them; I'll sort out any conflicts when I rebase. As a real carrot for a proper build system, tools like
This: Lines 74 to 75 in 572b934
Appreciate the pointer; I've pushed a commit to include the missing X11 dependencies on ImageMagick.
Evaluate at your leisure, please don't think I was implying that this should replace the build system for your upcoming release. As downstream packager I would love to see any replacement for Autotools considered at some point after that. As a final note I would like you to consider running Autotools and Meson (or CMake) side-by-side for a transition period - we can add a |
Kangie
force-pushed
the
a-proper-build-system
branch
8 times, most recently
from
618c06b to
94a8c81
Compare
Kangie
force-pushed
the
a-proper-build-system
branch
from
94a8c81 to
4579efc
Compare
Kangie
force-pushed
the
a-proper-build-system
branch
from
4579efc to
421db66
Compare
It's been a mandatory part of POSIX since 2001 an although it's an ISO C Extension, cstdint is ISO for C++ Signed-off-by: Matt Jolly <kangie@gentoo.org>
Kangie
force-pushed
the
a-proper-build-system
branch
from
421db66 to
4008e70
Compare
|
Rebased on current master, tidied up commit history and squashed meson commits down for comparison with #333 Builds fine, runs fine. Tests are running successfully but timing out - I can dig into that if further development is welcome. CI updated to use matrices to test as many options as possible, but not tested post merge; I expect failures here. I suspect the remaining issues to be tidied up are to do meson not successfully interpreting the test driver exiting, as my test logs show the diff coming back as |
|
It's probably worth, at the very least, cherry-picking the IWYU fixes. |
This is a first pass at porting autoconf/automake to Meson. Test driver modified to remove the trap on EXIT in favour of a function call after setting the exit code; this was causing meson test to hang on HTML tests and recording them as failed after the timeout. Signed-off-by: Matt Jolly <kangie@gentoo.org>
Use Matrix configurations to make a more concise config that builds both the Autotools and Meson build paths on supported platforms, and where possible uses Clang and GCC Signed-off-by: Matt Jolly <kangie@gentoo.org>
|
Tracked down hanging tests to the exit trap. If there's willingness to consider merging this I'm happy to tidy up the CI and look into test failures, but otherwise the port is "done", and is up-to-date with current master. |
|
Comment for Rodrigo: Do not adopt meson if you plan to support old UNIXes. Muon, the C99 Meson, is unfortunately poorly coded with poor support for aligned access on RISC systems and numerous problems (My main critique being, who peppers a setup with hundreds of asserts in a DEFAULT BUILD?), and boson, the C11 version, is poorly maintained. Out of all options, autotools is preferable, but CMake is workable. I understand as you are moving to C++11 that GCC moreorless will become the sole compiler, but dillo never properly built on anything else. I do not want to hurt Kengie's feelings or upset their effort, it's just, Meson is not an acceptable system for this project. CMake has additionally decent Windows support, if MS windows support is a priority. |
|
I hope you don't plan on compiling CMake on systems without a C++ (11) compiler. |
Building a build tool with GCC is different than building a program with a native compiler. There's hassles and problems with building GCC for everything on niche platforms. On IRIX, for instance, GCC cannot be effectively debugged even with restored GCC support from Kazuo K. or the SGUG GCC, the gdb system on IRIX can't debug threads, stack traces are funky. dbx expects dwarf of a certain kind. On Itanium and PA-RISC, GCC's C++ performance compared to HPE's is baaad. It's a bit better there, you got several compilers to choose from depending on OS (ICC, aCC, Pro64) but yeah, I think ya get my point. Regardless, I was offering my input. Dillo is a useful browser and you gotta get with the times, Cmake being a necessity is what it is. Meson and Muon are not acceptable IMHO for projects that target older systems. |
I also suspect the same, but I will need to do more research to be sure. This is not a priority now, so I will take some time to address other issues first. I recommend not investing more time in this PR until that is clarified on my side, otherwise you risk wasting your time.
We try to target 20+ year old stacks, including older gcc with no support for C++11 as we only need variadic macros from C++11 which are available in much older compilers. There is no public announcement about what we support and what not because is not an easy task to even measure (I don't have access to many of the old systems that claim to run Dillo). I won't change the build system until I have researched all platforms in which Dillo works currently and how it will be affected. And I would rather not maintain two build systems. If you @Sunny-Maxis want to help improving the support on IRIX that would be nice to have. Feel free to open another issue to track the current status and what we can do to improve it. |
CMake, when compiling itself, searches for a C++17 compiler, or a C++14 compiler, or a C++11 compiler, and if it cannot at least find a C++11 compiler it errors out with this code: if(NOT CMake_HAVE_CXX_UNIQUE_PTR)
message(FATAL_ERROR "The C++ compiler does not support C++11 (e.g. std::unique_ptr).")
endif()So I don't think you can use cmake if you target 20+ year old stacks. Meson can in theory run on any system with a c99 compiler, though it may require either:
to be ported to that system, possibly a much easier task than porting a C++ compiler. According to muon-build/muon#115
which indicates that python does work? Muon is definitely willing to accept patches, but it was made clear that IRIX in particular cannot be emulated, and uses a different MIPS ABI than other OSes running on MIPS, and @Sunny-Maxis decided it was too painful to debug (interesting assessment) so idk what to tell you. I am not convinced that experience is generally applicable to older systems. I suppose you could argue that the only option is to continue with autotools... |
For very old platforms it probably is the best tradeoff for now, but it slows down development on relatively modern ones. However the current issues I have with autotools are probably fixable with enough perseverance. |
I will definitely give it a shot when I'm at that point. It's going to be a hot minute more than likely because we are trying to get other stuff out of the way.
This is a fair assessment. However I can get a version of Cmake running on IRIX (3.8 or so) using a somewhat recent version of GCC without dealing with libuv, and people have gotten a later version of it running using their own tool chains. That is to say he could simply stick with an older version of Cmake as a minimum required version.
It's extremely painful to use meson on a system like IRIX. Unless you're cross compiling which I am not able to do with our setup because we are trying to use the native compiler whenever possible, and because my boss is of the opinion that cross compiling is not necessary on this particular system.
This is somewhat out of the scope for this discussion but I will briefly elaborate:
This is what I would recommend based on what's being said here. If you're going to Target windows as a platform at all honestly you should just tell people that they should have to fork and track the project separately with Ms build or something. The windows and UNIX universes are just not compatible on several levels. Regardless it's much easier to port GCC to a platform or reinstate support even, then to sometimes deal with poor upstream support or crap code. Sometimes dealing with projects like Muon, which I'm not saying was intentional on their part, feels like pulling teeth and I don't appreciate the way I was lectured on several occasions and told to just throw printf's everywhere. Rodrigo you'll be hearing from me when I do have something to show on dillo for IRIX. That'll probably be sometime in the next 3 to 4 months or so. That may not be that far off though that's just a rough estimate. |
4 participants
Hi Team,
While logging #262 I had the thought that it ought to be relatively straightforward to port Dillo to Meson.
I took a bit of time this afternoon and the result is an initial port.
It builds and links without complaint, but it's currently not producing a "working" dillo - I've missed something with DNS that I'll come back to shortly.
I know this wasn't specifically requested however I still think it's worthwhile:
muonandsamuraiwhich are C99 implementations of Meson and Ninja respectively.sh -c 'meson setup --wipe build ; ninja -C build' 18.87s user 7.74s system 958% cpu 2.777 totalsh -c './configure && make -j' 33.55s user 4.55s system 550% cpu 6.917 totalwhich;)I'll keep plugging away at this unless you're not interested until we can get it ready for release.
Closes: #262
Cheers,
Matt