switch build system? #146

stsp · 2020-10-02T12:38:47Z

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. :)

andrewbird · 2020-10-02T12:58:42Z

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.

stsp · 2020-10-02T13:19:51Z

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".

This allows to get Bionic back in. Xenial doesn't have lld, so remains broken.

stsp · 2020-10-02T15:27:39Z

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.

minexew · 2021-03-18T08:10:07Z

@stsp why do you write
everything
as a Haiku?

It's quite difficult
to parse.

stsp · 2021-03-18T15:32:22Z

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. :)

jschwartzenberg · 2021-03-20T07:43:39Z

I'm not sure that happened, I think @minexew is just generally curious about your automatic-wrapping-fobia ;)

stsp · 2023-10-28T12:00:18Z

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?

waruqi · 2023-10-28T14:46:03Z

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

stsp · 2023-10-28T16:16:57Z

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?

waruqi · 2023-10-28T16:35:51Z

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.

stsp · 2023-10-28T17:15:41Z

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!

stsp · 2023-10-28T17:22:14Z

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?

stsp · 2023-10-28T18:58:31Z

mesonbuild/meson#49
meson seems to be doing that
since 2015.

waruqi · 2023-10-29T02:27:56Z

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:

xmake-io/xmake#1433

The custom api feature in the recent dev release is actually in preparation for this packaging feature xmake-io/xmake#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.

stsp · 2023-10-29T06:13:50Z

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... :)

stsp · 2023-10-29T06:18:19Z

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.

waruqi · 2023-10-29T06:26:41Z

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. xmake-io/xmake#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.

waruqi · 2023-10-29T06:38:15Z

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.

stsp · 2023-10-29T07:09:16Z

24.04 ok, any ETA for fedora?

stsp · 2023-10-29T07:10:49Z

Ah, you mentioned fedora already, sorry.

stsp · 2023-10-29T07:54:12Z

You don't have Mantic builds on LP.
Why is so?

waruqi · 2023-10-29T07:57:41Z

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.

stsp · 2023-10-29T08:15:58Z

I mean this:
https://launchpad.net/~xmake-io/+archive/ubuntu/xmake
Can you add Mantic build?

waruqi · 2023-10-29T08:18:40Z

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.

stsp · 2023-10-29T08:24:24Z

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?

waruqi · 2023-10-29T09:37:38Z

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

stsp · 2023-10-29T09:42:02Z

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.

waruqi · 2023-10-29T10:16:10Z

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.

stsp · 2023-10-29T10:19:52Z

andrewbird · 2023-12-07T15:54:08Z

ajb@calypso:/clients/common/fdpp.git/build$ git diff
diff --git a/configure.meson b/configure.meson
index ab4d8666..ddd8b895 100755
--- a/configure.meson
+++ b/configure.meson
@@ -1,3 +1,8 @@
+#!/bin/sh
+
+
+set -xv
+
 if [ -f meson.build ]; then
     echo -e "Create a build dir first:"
     echo -e "\tmkdir build"

if [ -f meson.build ]; then
    echo -e "Create a build dir first:"
    echo -e "\tmkdir build"
    echo -e "\tcd build"
    echo -e "\t../$(basename $0)"
    echo "Bye!"
    exit 0
fi
+ [ -f meson.build ]

TOP=$(dirname "$0")
+ dirname ../configure.meson
+ TOP=..
meson setup --native-file $TOP/fdpp/toolchain.ini \
  --cross-file $TOP/fdpp/toolchain.ini \
  --cross-file $TOP/fdpp/kernel/toolchain.ini \
  --native-file $TOP/fdpp/kernel/toolchain.ini . $TOP --reconfigure
+ meson setup --native-file ../fdpp/toolchain.ini --cross-file ../fdpp/toolchain.ini --cross-file ../fdpp/kernel/toolchain.ini --native-file ../fdpp/kernel/toolchain.ini . .. --reconfigure
Directory does not contain a valid build tree:
/clients/common/fdpp.git/build
[ "$?" == "0" ] || exit 1
+ [ 1 == 0 ]
../configure.meson: 20: [: 1: unexpected operator
+ exit 1

andrewbird · 2023-12-07T15:56:21Z

so I think line 20 should be [ "$?" = "0" ] || exit 1 i.e. single =, but that's after the error

stsp · 2023-12-07T16:10:30Z

Ok, not sure what does this mean.
From that build dir you can do:

$ find .. -name meson.build
../fdpp/thunk_gen/meson.build
../fdpp/kernel/meson.build
../fdpp/loader/meson.build
../fdpp/meson.build
../meson.build

Do you see the same?

andrewbird · 2023-12-07T16:12:53Z

ajb@calypso:/clients/common/fdpp.git/build$ find .. -name meson.build
../fdpp/thunk_gen/meson.build
../fdpp/kernel/meson.build
../fdpp/loader/meson.build
../fdpp/meson.build
../meson.build

andrewbird · 2023-12-07T16:16:07Z

this page https://mesonbuild.com/Configuring-a-build-directory.html suggests there's a step called meson configure

stsp · 2023-12-07T16:17:48Z

Please try to remove --reconfigure
from script. Maybe in your version it
requires configured build tree.

andrewbird · 2023-12-07T16:19:32Z

yes that got further

ajb@calypso:/clients/common/fdpp.git/build$ ../configure.meson

if [ -f meson.build ]; then
    echo -e "Create a build dir first:"
    echo -e "\tmkdir build"
    echo -e "\tcd build"
    echo -e "\t../$(basename $0)"
    echo "Bye!"
    exit 0
fi
+ [ -f meson.build ]

TOP=$(dirname "$0")
+ dirname ../configure.meson
+ TOP=..
meson setup --native-file $TOP/fdpp/toolchain.ini \
  --cross-file $TOP/fdpp/toolchain.ini \
  --cross-file $TOP/fdpp/kernel/toolchain.ini \
  --native-file $TOP/fdpp/kernel/toolchain.ini . $TOP
+ meson setup --native-file ../fdpp/toolchain.ini --cross-file ../fdpp/toolchain.ini --cross-file ../fdpp/kernel/toolchain.ini --native-file ../fdpp/kernel/toolchain.ini . ..
The Meson build system
Version: 0.61.2
Source dir: /clients/common/fdpp.git
Build dir: /clients/common/fdpp.git/build
Build type: cross build
Project name: fdpp
Project version: 0.1
C compiler for the host machine: gcc (gcc 11.4.0 "gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0")
C linker for the host machine: gcc ld.bfd 2.38
C++ compiler for the host machine: clang++ (clang 14.0.0-1ubuntu1 "Ubuntu clang version 14.0.0-1ubuntu1.1")
C++ linker for the host machine: clang++ ld.bfd 2.38

../meson.build:1:0: ERROR: Tried to use unknown language "nasm".

A full log can be found at /clients/common/fdpp.git/build/meson-logs/meson-log.txt
[ "$?" = "0" ] || exit 1
+ [ 1 = 0 ]
+ exit 1

stsp · 2023-12-07T16:26:31Z

Added patch, can you please re-check?

andrewbird · 2023-12-07T16:29:04Z

Well that's the Jammy build stuffed then

ajb@calypso:/clients/common/fdpp.git/build$ ../configure.meson
The Meson build system
Version: 0.61.2
Source dir: /clients/common/fdpp.git
Build dir: /clients/common/fdpp.git/build
Build type: cross build

../meson.build:1:0: ERROR: Meson version is 0.61.2 but project requires >= 0.64

A full log can be found at /clients/common/fdpp.git/build/meson-logs/meson-log.txt

stsp · 2023-12-07T16:34:56Z

Sigh.
Your meson is just 2 years old,
but there is no nasm yet.
And in fact I suspect we'll fsck
on anything before 1.0, which is
dated dec 2022, so 1 year old...
I didn't know meson have just
emerged.
Hmm, unsure what to do now.

andrewbird · 2023-12-07T16:37:37Z

I tend to follow the Ubuntu LTS series, so come April all will be good!

stsp · 2023-12-07T16:41:44Z

I am not quite sure things will improve
much... unless we want to drop everything
but 2024 LTS? :(
I guess we'll be able to switch CI to meson
at April, but seems like makefiles will have
to be supported in parallel for quite a years
to come. Which puts a big question mark
on this entire work.

andrewbird · 2023-12-07T16:44:03Z

is there an updated meson in a PPA we could use?

stsp · 2023-12-07T16:46:24Z

That's an interesting question.
In fact, as its written on python, we
probably can just use the Noble's
packages on any ubuntu.
Let me tell you secretly that I have
actually done exactly that. :) Just
forgot in 2 weeks of porting.

So... can you try to just to update to
the Noble build? IIRC there was no
such PPA, or why would I otherwise
use the Noble build myself.

andrewbird · 2023-12-07T17:39:32Z

ajb@calypso:/clients/common/fdpp.git/build$ sudo apt remove meson

ajb@calypso:/clients/common/fdpp.git/build$ sudo apt install ninja-build
[sudo] password for ajb: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed
  ninja-build
0 to upgrade, 1 to newly install, 0 to remove and 0 not to upgrade.
Need to get 111 kB of archives.
After this operation, 358 kB of additional disk space will be used.
Get:1 http://gb.archive.ubuntu.com/ubuntu jammy/universe amd64 ninja-build amd64 1.10.1-1 [111 kB]
Fetched 111 kB in 0s (301 kB/s)       
Selecting previously unselected package ninja-build.
(Reading database ... 328447 files and directories currently installed.)
Preparing to unpack .../ninja-build_1.10.1-1_amd64.deb ...
Unpacking ninja-build (1.10.1-1) ...
Setting up ninja-build (1.10.1-1) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for doc-base (0.11.1) ...
Processing 1 added doc-base file...

ajb@calypso:/clients/common/fdpp.git/build$ pip3 install meson
Defaulting to user installation because normal site-packages is not writeable
Collecting meson
  Downloading meson-1.3.0-py3-none-any.whl (976 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 976.4/976.4 KB 5.0 MB/s eta 0:00:00
Installing collected packages: meson
  WARNING: The script meson is installed in '/home/ajb/.local/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed meson-1.3.0
ajb@calypso:/clients/common/fdpp.git/build$ export PATH=/home/ajb/.local/bin:${PATH}

ajb@calypso:/clients/common/fdpp.git/build$ ../configure.meson
The Meson build system
Version: 1.3.0
Source dir: /clients/common/fdpp.git
Build dir: /clients/common/fdpp.git/build
Build type: cross build
Project name: fdpp
Project version: 0.1
Nasm compiler for the host machine: nasm-segelf (nasm 2.17)
Nasm linker for the host machine: gcc ld.bfd 2.38
C compiler for the host machine: gcc (gcc 11.4.0 "gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0")
C linker for the host machine: gcc ld.bfd 2.38
C++ compiler for the host machine: clang++ (clang 14.0.0-1ubuntu1 "Ubuntu clang version 14.0.0-1ubuntu1.1")
C++ linker for the host machine: clang++ ld.bfd 2.38
Nasm compiler for the build machine: nasm-segelf (nasm 2.17)
Nasm linker for the build machine: gcc ld.bfd 2.38
C compiler for the build machine: gcc (gcc 11.4.0 "gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0")
C linker for the build machine: gcc ld.bfd 2.38
C++ compiler for the build machine: clang++ (clang 14.0.0-1ubuntu1 "Ubuntu clang version 14.0.0-1ubuntu1.1")
C++ linker for the build machine: clang++ ld.bfd 2.38
Build machine cpu family: x86_64
Build machine cpu: x86_64
Host machine cpu family: x86
Host machine cpu: i386
Target machine cpu family: x86
Target machine cpu: i386

Executing subproject libfdpp 

libfdpp| Project name: libfdpp
libfdpp| Project version: 0.1
libfdpp| C compiler for the host machine: gcc (gcc 11.4.0 "gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0")
libfdpp| C linker for the host machine: gcc ld.bfd 2.38
libfdpp| C++ compiler for the host machine: clang++ (clang 14.0.0-1ubuntu1 "Ubuntu clang version 14.0.0-1ubuntu1.1")
libfdpp| C++ linker for the host machine: clang++ ld.bfd 2.38
libfdpp| C compiler for the build machine: gcc (gcc 11.4.0 "gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0")
libfdpp| C linker for the build machine: gcc ld.bfd 2.38
libfdpp| C++ compiler for the build machine: clang++ (clang 14.0.0-1ubuntu1 "Ubuntu clang version 14.0.0-1ubuntu1.1")
libfdpp| C++ linker for the build machine: clang++ ld.bfd 2.38

Executing subproject libfdpp:thunk_gen

thunk_gen| Project name: thunk_gen
thunk_gen| Project version: 0.1
thunk_gen| C compiler for the host machine: gcc (gcc 11.4.0 "gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0")
thunk_gen| C linker for the host machine: gcc ld.bfd 2.38
thunk_gen| C compiler for the build machine: gcc (gcc 11.4.0 "gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0")
thunk_gen| C linker for the build machine: gcc ld.bfd 2.38
thunk_gen| Program flex found: YES (/usr/bin/flex)
thunk_gen| Program bison found: YES (/usr/bin/bison)
thunk_gen| Build targets in project: 1
thunk_gen| Subproject thunk_gen finished.

libfdpp| Fetching value of define "FDPP_API_VER" : 35
libfdpp| Fetching value of define "BPRM_VER" : 10
libfdpp| Program /clients/common/fdpp.git/subprojects/libfdpp/parsers/mkfar.sh found: YES (/clients/common/fdpp.git/subprojects/libfdpp/parsers/mkfar.sh)
libfdpp| Program /clients/common/fdpp.git/subprojects/libfdpp/parsers/parse_decls.sh found: YES (/clients/common/fdpp.git/subprojects/libfdpp/parsers/parse_decls.sh)
libfdpp| Program autom4te found: YES (/usr/bin/autom4te)
libfdpp| Program echo found: YES (/usr/bin/echo)
libfdpp| Build targets in project: 9
libfdpp| Subproject libfdpp finished.


Executing subproject loader 

loader| Project name: loader
loader| Project version: 0.1
loader| C compiler for the host machine: gcc (gcc 11.4.0 "gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0")
loader| C linker for the host machine: gcc ld.bfd 2.38
loader| C compiler for the build machine: gcc (gcc 11.4.0 "gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0")
loader| C linker for the build machine: gcc ld.bfd 2.38
loader| Found pkg-config: YES (/usr/bin/pkg-config) 1.8.0
loader| Run-time dependency libelf found: YES 0.186
loader| Fetching value of define "FDPP_API_VER" : 35
loader| Fetching value of define "BPRM_VER" : 10
loader| Build targets in project: 10
loader| Subproject loader finished.


Executing subproject kernel 

kernel| Project name: kernel
kernel| Project version: 1.7
kernel| Nasm compiler for the host machine: nasm-segelf (nasm 2.17)
kernel| Nasm linker for the host machine: gcc ld.bfd 2.38
kernel| C compiler for the host machine: gcc (gcc 11.4.0 "gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0")
kernel| C linker for the host machine: gcc ld.bfd 2.38
kernel| Nasm compiler for the build machine: nasm-segelf (nasm 2.17)
kernel| Nasm linker for the build machine: gcc ld.bfd 2.38
kernel| C compiler for the build machine: gcc (gcc 11.4.0 "gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0")
kernel| C linker for the build machine: gcc ld.bfd 2.38
kernel| Fetching value of define "FDPP_API_VER" : 35
kernel| Fetching value of define "BPRM_VER" : 10
kernel| Program i686-linux-gnu-ld found: YES (/usr/bin/i686-linux-gnu-ld)
kernel| Build targets in project: 15
kernel| Subproject kernel finished.

Build targets in project: 15

fdpp 0.1

  Subprojects
    kernel      : YES
    libfdpp     : YES
    loader      : YES
    thunk_gen   : YES (from libfdpp)

  User defined options
    Cross files : ../fdpp/toolchain.ini
                  ../fdpp/kernel/toolchain.ini
    Native files: ../fdpp/toolchain.ini
                  ../fdpp/kernel/toolchain.ini

Found ninja-1.10.1 at /usr/bin/ninja

Done configure
Now run "meson build --verbose" to build
After that you can do "sudo meson install" to install

ajb@calypso:/clients/common/fdpp.git/build$ meson build --verbose
usage: meson [-h] {setup,configure,dist,install,introspect,init,test,wrap,subprojects,rewrite,compile,devenv,env2mfile,help} ...
meson: error: unrecognized arguments: --verbose

ajb@calypso:/clients/common/fdpp.git/build$ meson build

ERROR: Neither source directory 'build' nor build directory None contain a build file meson.build.
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.

stsp · 2023-12-07T17:42:33Z

Wow!
Let me do just that...

andrewbird · 2023-12-07T17:44:41Z

You probably have to remove the packaged meson to be sure of getting the pip3 installed one.

stsp · 2023-12-07T17:48:11Z

I did.
Except that pip3 complained and asked
me to please use pipx instead. :)
As to your problem, try running ninja
as a work-around.
This meson, while matches my version
numerically, behaves very differently...

andrewbird · 2023-12-07T17:49:34Z

It should have been meson compile.

ajb@calypso:/clients/common/fdpp.git/build$ meson compile
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja
[17/122] Compiling C object subprojects/libfdpp/subprojects/thunk_gen/thunk_gen.p/meson-generated_thunk_gen.l.yy.c.o
subprojects/libfdpp/subprojects/thunk_gen/thunk_gen.p/thunk_gen.l.yy.c:1518:16: warning: ‘input’ defined but not used [-Wunused-function]
 1518 |     static int input  (void)
      |                ^~~~~
subprojects/libfdpp/subprojects/thunk_gen/thunk_gen.p/thunk_gen.l.yy.c:1475:17: warning: ‘yyunput’ defined but not used [-Wunused-function]
 1475 |     static void yyunput (int c, char * yy_bp )
      |                 ^~~~~~~
[122/122] Linking target subprojects/libfdpp/libfdpp.so.35.10

stsp · 2023-12-07T17:52:09Z

Yes, that's true.
Silly me. :)
Fixed.

andrewbird · 2023-12-07T17:54:11Z

I'll see if I can get it to work on CI now.

stsp · 2023-12-07T18:00:47Z

Please use pipx on CI to stay on the same
boat with me.

stsp · 2023-12-08T18:01:02Z

OK, one problem fixed:
mesonbuild/meson#12608
mesonbuild/meson#12610
Now if also this is fixed:
mesonbuild/meson#12609
then I'll be able to provide a meson-based
fall-back for nasm-segelf. And that would be
the last major task within this ticket.

There are a few more bugs I filled against
meson, but they are minor and can wait.
Just 1 outstanding bug remained.
Which is quite amazing.
Meson actually successfully does 95% of
things I was throwing on it, and in most
cases when not - the work-arounds were
not too bad.

stsp · 2024-03-26T04:12:55Z

Fedora builds are no longer using pipx
for installing meson, as fedora-39 got
meson-1.3.2 via updates.
Whereas ubuntu builds are still on a
makefiles, as getting new meson even
in ubuntu-22.04 seems unlikely...

This requires meson-1.3.2.

1.3.0 is required for `env` in `generator.process()`. dependency.get_pkgconfig_variable() is deprecated.

volkertb · 2024-11-10T17:33:42Z

@stsp Before opening a new ticket about this:

I can't build the most recent master of fdpp. Both ./configure and ./configure.meson complain about not finding thunk_gen, even though I had pulled that repo and had built it and installed it as well, using the commands ./configure ; meson compile --verbose -C build ; sudo meson install -C build.

And I'm just building a new version of fdpp to satisfy the dosemu2 build.

I'm sure you've had good reasons to make these changes, but it has gotten noticeably harder to build dosemu2 from source than it used to be.

stsp · 2024-11-10T17:46:11Z

You simply have problems with
pkg-config. Namely, with PKG_CONFIG_PATH.
See pkg-config --cflags thunk_gen

stsp · 2024-11-10T17:47:48Z

but it has gotten noticeably harder to build dosemu2 from source than it used to be.

But you can use ubuntu or fedora packages,
and also flatpak.

stsp added a commit that referenced this issue Oct 2, 2020

switch back to binutils objcopy [#146]

24a252a

This allows to get Bionic back in. Xenial doesn't have lld, so remains broken.

stsp added a commit that referenced this issue Apr 18, 2024

meson: use compile_args in preprocess() [#146]

4218062

This requires meson-1.3.2.

stsp added a commit that referenced this issue Apr 18, 2024

meson: update script in libfdpp subproject [#146]

e39aa5e

1.3.0 is required for `env` in `generator.process()`. dependency.get_pkgconfig_variable() is deprecated.

jschwartzenberg mentioned this issue Aug 17, 2024

Hardcoded x86_64 ld #251

Closed

switch build system? #146

switch build system? #146

Comments

stsp commented Oct 2, 2020

andrewbird commented Oct 2, 2020

stsp commented Oct 2, 2020

stsp commented Oct 2, 2020

minexew commented Mar 18, 2021

stsp commented Mar 18, 2021

jschwartzenberg commented Mar 20, 2021

stsp commented Oct 28, 2023

waruqi commented Oct 28, 2023

stsp commented Oct 28, 2023

waruqi commented Oct 28, 2023

stsp commented Oct 28, 2023 • edited Loading

stsp commented Oct 28, 2023 • edited Loading

stsp commented Oct 28, 2023

waruqi commented Oct 29, 2023 • edited Loading

stsp commented Oct 29, 2023

stsp commented Oct 29, 2023

waruqi commented Oct 29, 2023 • edited Loading

waruqi commented Oct 29, 2023

stsp commented Oct 29, 2023

stsp commented Oct 29, 2023

stsp commented Oct 29, 2023

waruqi commented Oct 29, 2023

stsp commented Oct 29, 2023

waruqi commented Oct 29, 2023

stsp commented Oct 29, 2023

waruqi commented Oct 29, 2023 • edited Loading

stsp commented Oct 29, 2023

waruqi commented Oct 29, 2023 • edited Loading

stsp commented Oct 29, 2023

andrewbird commented Dec 7, 2023

andrewbird commented Dec 7, 2023

stsp commented Dec 7, 2023

andrewbird commented Dec 7, 2023

andrewbird commented Dec 7, 2023

stsp commented Dec 7, 2023

andrewbird commented Dec 7, 2023

stsp commented Dec 7, 2023

andrewbird commented Dec 7, 2023

stsp commented Dec 7, 2023

andrewbird commented Dec 7, 2023

stsp commented Dec 7, 2023

andrewbird commented Dec 7, 2023

stsp commented Dec 7, 2023

andrewbird commented Dec 7, 2023

stsp commented Dec 7, 2023

andrewbird commented Dec 7, 2023

stsp commented Dec 7, 2023

andrewbird commented Dec 7, 2023

stsp commented Dec 7, 2023

andrewbird commented Dec 7, 2023

stsp commented Dec 7, 2023

stsp commented Dec 8, 2023

stsp commented Mar 26, 2024

volkertb commented Nov 10, 2024

stsp commented Nov 10, 2024

stsp commented Nov 10, 2024

stsp commented Oct 28, 2023 •

edited

Loading

stsp commented Oct 28, 2023 •

edited

Loading

waruqi commented Oct 29, 2023 •

edited

Loading

waruqi commented Oct 29, 2023 •

edited

Loading

waruqi commented Oct 29, 2023 •

edited

Loading

waruqi commented Oct 29, 2023 •

edited

Loading