dosemu2
switch build system?
Currently (in master) fdpp is only buildable on focal and groovy. Bionic misses llvm-objcopy so that binutils is needed, and Xenial misses lld, so binutils is needed. There are a few ways to solve that:
- Revert back to objcopy(binutils) and forget about Xenial and about llvm-only build.
- Revert back to objcopy+ld.bfd (binutils) and forget about non-binutils builds forever.
- Switch to xmake and do non-binutils builds when possible.
- Create fdpp-legacy
- Do nothing
Case 3 can only work if you can, as @andrewbird suggests, say "lld | binutils" in Build-Depends.
I would personally think I'd go for 1 unless @jschwartzenberg moves things to 3. :)
I can swap Travis to use focal for both fdpp and dosemu2, which is probably the right thing to do now anyway.
Option 4 seems to align quite nicely with dosemu-legacy. Option 3 is my least favourite, as I'd prefer that parallel builds worked sensibly with make, but of course I don't have to maintain the build system.
Locally I'm still using Bionic simply because the Lubuntu on Focal is so awful after its switch to the Qt tookit, that it was unusable! I'm probably going to need to switch desktops to Xubuntu which breaks my heart as Lubuntu on Bionic is just right for me.
I don't prefer 4 here because, unlike in dosemu2, where old builds reduce both security and functionality, here nothing is changed at all. So such separation here makes much less sense than there.
make was never a problem here (unlike in dosemu2), so I am not a big fan of 3 too, but some configure step may be helpful, as it is turning out now:
- bfd/lld/gold
- nasm/yasm
- llvm-objcopy/objcopy
- clang/gcc (not any soon)
- sed/gsed (see parse_decls.sh where I probe for gsed by hands)
- various flavours of
install(worked to a common denominator already)
Build options:
- debug/non-debug/extra-debug
- use/unuse sanitizers
I'd say, the list is not as small as it was when I thought "oh, 10-lines makefile will suffice".
I reverted to objcopy to get at least Bionic back. But I still think its time to get configure, as too many build-time uncertainty have accumulated.
@stsp why do you write everything as a Haiku?
It's quite difficult to parse.
I think you see the automatic line-wrapping laying on top of the manual ones. I am trying to keep the lines short to avoid automatic wraps from ever happening, but sometimes they happen nevertheless. Resulting in something like this. :)
I'm not sure that happened, I think @minexew is just generally curious about your automatic-wrapping-fobia ;)
I think its time to push this forward again, as it seems we'll need to switch from lld to GNU ld, which doesn't support the cross-compilation for free. I.e. lld supports all targets at once, whereas GNU ld needs to be installed in a special cross-build form. I looked into xmake docs, and it says is has a package management of its own, as well as supporting the native package managers. apt is listed, but rpm/dnf - not. @waruqi are you planning the dnf/rpm support? Also I wonder how exactly I can benefit from that package management. For the LP/COPR work-flows I think it would be very cool if xmake could just generate the rpkg and debuild specs automatically, with all the needed deps. Basically I think this is more about an integration with native builders, rather with package managers. I.e. it would be cool if xmake could, besides installing deps and building the package on its own, also generate the needed spec, on which debuild/rpkg can be used. Can it do something like this?
but rpm/dnf - not. @waruqi are you planning the dnf/rpm support?
It may be considered in the future, and you can open a feature request first. We now support other package managers in addition to apt, such as conan/vcpkg/pacman/zypper/portage.
Basically I think this is more about an integration with native builders, rather with package managers. I.e. it would be cool if xmake could, besides installing deps and building the package on its own, also generate the needed spec, on which debuild/rpkg can be used. Can it do something like this?
like cmake/cpack? We are also planning to implement a similar feature to generate deb/nsis/rpm packages, but it may take some time, maybe a few more releases. Next release we will start with an initial implementation of support for nsis packages. Then we'll move on to support other packages like deb, rpm, etc.
BTW, xmake has been in the debian and archlinux repository. https://packages.debian.org/sid/xmake
Generating packages is probably not what I need. I am looking for generating only the specs for lp/copr/obs work-flows. Is something like that planned?
Generating packages is probably not what I need. I am looking for generating only the specs for lp/copr/obs work-flows. Is something like that planned?
I don't understand the format of these files. Maybe you can say more detail, or you can generate them yourself by way of a custom task.
rpkg: https://github.com/dosemu2/fdpp/blob/master/fdpp.spec.rpkg deb: https://github.com/dosemu2/fdpp/blob/master/debian/control obs: https://build.opensuse.org/package/view_file/home:stsp2/fdpp/fdpp.spec?expand=1
I of course can generate them by hands, but:
- the build system has all the needed info for them
- whenever the dep is changed, I need to update 4 places!
We are also planning to implement a similar feature to generate deb/nsis/rpm packages
Note that you will very likely need to generate these specs anyway, if you want to build the appropriate package. Because the build tools need it. Of course unless you somehow can build packages by xmake "directly", bypassing the host tools. Which I don't think is possible, or?
https://github.com/mesonbuild/meson/issues/49 meson seems to be doing that since 2015.
We are also planning to implement a similar feature to generate deb/nsis/rpm packages
Note that you will very likely need to generate these specs anyway, if you want to build the appropriate package. Because the build tools need it. Of course unless you somehow can build packages by xmake "directly", bypassing the host tools. Which I don't think is possible, or?
Yes, I meant to generate these specs for packaging. xmake doesn't generate package binary directly. It generates all kinds of specs and then calls debuild, nsismake and other packaging tools to generate it. In addition, it does better automation, such as automatically installing required tools(debuild, nsismake ...) and then calling them.
Of course, we can also tell xmake to only generate specs and not to auto-package them by using the policy configuration.
mesonbuild/meson#49 meson seems to be doing that since 2015.
We also have a related issue:
https://github.com/xmake-io/xmake/issues/1433
The custom api feature in the recent dev release is actually in preparation for this packaging feature https://github.com/xmake-io/xmake/issues/4276
And we're already planning to implement the initial nsis spec generation in 2.8.6, as well as some initial design of the packaging and configuration APIs. If all goes well, and I have enough time, I will start trying to implement deb and rpm spec generation and packaging in 2.8.7. Of course, I haven't decided which one to implement first.
Thanks, this all sounds promising. The only problem is that something like 5 years ago I was getting the same answers, and there is afaics still no xmake in debian or fedora... :)
Also you likely know that there is a small difference between rpm and rpkg specs. Copr uses rpkg, obs uses rpm, but rpm spec can be generated from rpkg spec, so it might be better to generate rpkg, not rpm spec.
Thanks, this all sounds promising. The only problem is that something like 5 years ago I was getting the same answers, and there is afaics still no xmake in debian or fedora... :)
We've been working on historical issues and we just recently resolved a 2 year old issue. https://github.com/xmake-io/xmake/issues/1452
It will take more time because I'm the only one maintaining it.
Also, xmake has recently been in debian. https://packages.debian.org/sid/xmake
By the time ubuntu 24.04 is released, we can get it.
And xmake has also been in archlinux.
There is also a fedora packager who is helping us package xmake into the fedora repositories, although I'm not sure when I'll be able to get in yet.
Also you likely know that there is a small difference between rpm and rpkg specs. Copr uses rpkg, obs uses rpm, but rpm spec can be generated from rpkg spec, so it might be better to generate rpkg, not rpm spec.
We'll deal with those differences when we start working on this.
You don't have Mantic builds on LP. Why is so?
xmake was just uploaded to the debian repositories last week, and ubuntu 23.10 has been frozen.
I mean this: https://launchpad.net/~xmake-io/+archive/ubuntu/xmake Can you add Mantic build?
I mean this: https://launchpad.net/~xmake-io/+archive/ubuntu/xmake Can you add Mantic build?
I haven't added it to the ppa package yet, it will be included in the next xmake release.
I don't understand. I enable the new builds with 1 mouse click. What's the use waiting for the next release, to just enable the build on LP? I simply can't apt-get it right now. Why to wait?
I don't understand. I enable the new builds with 1 mouse click. What's the use waiting for the next release, to just enable the build on LP? I simply can't apt-get it right now. Why to wait?
I don't know how to enable it on the web fastly, at the moment I can only upload it via ci when a new version is released. https://github.com/xmake-io/xmake/blob/042c51144c1a918d75493a94094e29aeafd924ff/.github/workflows/linux.yml#L50
Hmm, not sure. Today I went to LP UI and enabled the "Noble" build of fdpp by just checking in the checkbox. I always did so before, too. I can't give you any hints, as the only thing I know to do on LP, is to mouse-click through their convoluted UIs. I am currently uploading my nasm fork there, finding the click-through ways, and am enabling the needed builds w/o problems.
Hmm, not sure. Today I went to LP UI and enabled the "Noble" build of fdpp by just checking in the checkbox. I always did so before, too. I can't give you any hints, as the only thing I know to do on LP, is to mouse-click through their convoluted UIs. I am currently uploading my nasm fork there, finding the click-through ways, and am enabling the needed builds w/o problems.
I didn't find the corresponding checkbox, but I've uploaded it by modifying the script to use a temporary ci to upload it. You can try it again.