Skip to content

Conversation

@aheejin
Copy link
Member

@aheejin aheejin commented Jan 3, 2026

We cannot give different cflags depending on the file extensions in the current system_libs.py. This can be necessary when a library contains files with multiple extesnsions and some flags only work on a single extension. For example, -std=c23 only works on .c files, while -std=c++23 only on .cpp files.

This adds a filename argument to the system library builder, so that we later can allow different cflags for different extensions. This also handles USE_NINJA path.

A test for libunwind is added that we compile .c files with -std=c23 and .cpp files with -std=c++23. (This we want to do for LLVM 21 anyway)

We cannot give different cflags depending on the file extensions in the
current `system_libs.py`. This can be necessary when a library contains
files with multiple extesnsions and some flags only work on a single
extension. For example, `-std=c23` only works on .c files, while
`-std=c++23` only on .cpp files.

This adds a `filename` argument to the system library builder, so that
we later can allow different cflags for different extensions.
@aheejin aheejin requested a review from sbc100 January 3, 2026 23:42
@sbc100
Copy link
Collaborator

sbc100 commented Jan 8, 2026

We cannot give different cflags depending on the file extensions in the current system_libs.py. This can be necessary when a library contains files with multiple extesnsions and some flags only work on a single extension. For example, -std=c23 only works on .c files, while -std=c++23 only on .cpp files.

This adds a filename argument to the system library builder, so that we later can allow different cflags for different extensions.

Yes, I think this approach is probably better so we match upstream flags.

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the filename argument need to be optional?

cmd += get_base_cflags(self.build_dir, preprocess=False)
else:
cmd += cflags
cmd += self.get_cflags(src)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we already have the extension calculated here perhaps we can add self.cxxflags here when we have a cxx extension?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if I understand... We don't have self.cflags either. Do you want to add both? But then why would we have both self.cflags and self.get_cflags() then?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do have self.cflags and the default self.get_cflags() will read from this field.

The idea is that for simple libraries where the cflags don't vary you can just do cflags = ['x', 'y', 'z'] at the class level.

See libunwind for example.

In this case we could just add support for cxxflags = ['x', 'y', 'z']?

@aheejin
Copy link
Member Author

aheejin commented Jan 9, 2026

Does the filename argument need to be optional?

No I don't think so. Changed to a normal argument.

This adds a test that we compile .c and .cpp files in libunwind with
different cflags: .c with `-std=c23`, .cpp with `-std=c++23`.
@aheejin aheejin marked this pull request as ready for review January 9, 2026 10:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants