Add libbpf as a submodule

[jordalgo]

This is to potentinally reduce issues with folks using different versions of libbpf at runtime.

[Byte-Lab]

Nice, thanks! This will hopefully make things way less annoying for people. LGTM, just left a couple comments before stamping.

[Byte-Lab]

Should we make this the default behavior, and instead allow people to override libbpf_a to something else?

[jordalgo]

That makes sense. Will update

[arighi]

Not a blocker, but if we want to make this the default, it'd be nice if the build script would automatically run a git submodule update --init --recursive, so that it'll automatically fetch/update the submodule if it's not present (i.e. we could check if the dir libbpf/src esists).

This can prevent issues with people cloning the repo without git clone --recursive for example.

[Byte-Lab]

Agreed. Ideally the build script can minimize the pain of working with submodules by hiding the details when possible.

[ptr1337]

Could be this directly added into meson/scx add provide a option to use statically or dynamically linked one?

[jordalgo]

@ptr1337 Probably my ignorance of meson, but I don't quite understand your comment. Isn't the libbpf_a user option deciding if libbpf is statically linked or not?

[ptr1337]

@ptr1337 Probably my ignorance of meson, but I don't quite understand your comment. Isn't the libbpf_a user option deciding if libbpf is statically linked or not?

See Decave's comment

[Byte-Lab]

@ptr1337 Probably my ignorance of meson, but I don't quite understand your comment. Isn't the libbpf_a user option deciding if libbpf is statically linked or not?

I think what he's requesting is:

• Make static linking the default behavior
  • By default, statically link against the submodule libbpf
  • Else, allow user to specify another library to statically link against. Honestly, not sure we even need this?
• Else, allow user to dynamically link against libbpf.so

[jordalgo]

@ptr1337 Probably my ignorance of meson, but I don't quite understand your comment. Isn't the libbpf_a user option deciding if libbpf is statically linked or not?

I think what he's requesting is:

• Make static linking the default behavior

  • By default, statically link against the submodule libbpf
  • Else, allow user to specify another library to statically link against. Honestly, not sure we even need this?

• Else, allow user to dynamically link against libbpf.so

Cool. I think I did this in my latest changes - please correct me if I missed something.

The last thing I'll do is have meson do the git submodule update --init --recursive as @arighi suggested.

[jordalgo]

Actually, can we land this as is and I'll add the git submodule update --init --recursive in a follow up PR (mostly so I can test a fresh clone).

[jordalgo]

@Decave @htejun - Ok to merge?

[Byte-Lab]

LGTM, if you wouldn't mind please fixing the one typo, I can merge

[Byte-Lab]

Missing a space between ~ and -D

[jordalgo]

Whoops. Good catch.

[jordalgo]

Fixed