coredata: fix compiler base option recognized as "Unknown options" on an already configured directory.

[rlavarec-gpsw]

Fix error: ERROR: Unknown options: "b_lto"

cmd line:

meson setup --prefix C:\code\dev\yyyy\venv --pkg-config-path C:\vcpkg\installed\x64-windows\lib\pkgconfig;C:\code\dev\yyyy\venv\Lib\pkgconfig --buildtype release --debug -Db_lto=true --bindir=Scripts --libdir=Lib --includedir=Include -Db_vscrt=md --backend=vs2022 -Dtests=false C:\code\dev\yyyy\external\pkgconf external\pkgconf\builddir

[rlavarec-gpsw]

Hello @jpakkane

The error seems unrelated

  File "/cygdrive/d/a/meson/meson/mesonbuild/dependencies/cmake.py", line 225, in _get_cmake_info
    cmake_root=temp_parser.get_cmake_var('MESON_CMAKE_ROOT')[0],
IndexError: list index out of range

Do you have a clue ?

Thanks Renan

[rlavarec-gpsw]

@eli-schwartz The fix is a minimal change to prevent . ERROR: Unknown options: "b_lto"

[rlavarec-gpsw]

Gentle bump

[rlavarec-gpsw]

Gentle bump

[rlavarec-gpsw]

Hello, Could it be merge ?

[rlavarec-gpsw]

@eli-schwartz Hello Gentle bump, The code is not yet integrated to the main branch.

If you add into the command line on an already builded project, -Db_lto=true

You get ERROR: Unknown options: "b_lto"

This is fixing the problem.

I could add a test too if you want.

[rlavarec-gpsw]

Hello @jpakkane, @eli-schwartz, @xclaesse, Do you think the fix is ready ? Or there is a potential problem with it ?

[dnicolodi]

I don't understand how make/nmake (mentioned in the PR title and in the commit message) enter the picture. Could you elaborate?

[rlavarec-gpsw]

@dnicolodi Sorry we are using nmake/make to call meson scripts. It is not related. I updated the commit message. This still reproduce in 1.4.0

[rlavarec-gpsw]

When I do apply my patch locally, it is fixing the problem.

[rlavarec-gpsw]

It seems the failing tests are not due to my PR.

[eli-schwartz]

GitHub is currently having an outage whereby the VM kernel for Linux is a Ubuntu kernel and incompatible with sanitizers. It can't be fixed by using your own container.

They said they fixed it but won't deploy it until next week Friday...

[bruchar1]

I think this fix is ok.

[dnicolodi]

I'm sure we need tests for this 🙂 The last time the options parsing code was touched we introduced two regressions...

[rlavarec-gpsw]

Some test where added between the beginning of my PR and now, because my first commit was simpler and was only testing if k.type == OptionType.BASE. It was passing the CI in december. Because of some tests added since, this is not working anymore, because some args in unit test use "b_something" and are not in the list of base_options. So I added a test to be sure it is inside the list of "base_options". I think the CI cover it now.

[dcbaker]

~~I'd like to see a test added for this, or it's going to regress at some point.~~

~~I also think this is okay, but the option parsing code is complicated...~~

Wait, you're getting an unknown option b_lto when you pass -Db_lto to a compiler that doesn't support LTO? I'm not sure if ignoring that is the right solution.

[rlavarec-gpsw]

I didn't check if it is was implemented inside meson for vs2022 But b_lto (Use link time optimization) is base option available for all compiler as it is flag inside meson doc. And the option exist inside VisualStudio (/LTCG:PGOptimize)

[rlavarec-gpsw]

Without this fix:

Directory already configured.
ERROR: Unknown options: "b_lto"
NMAKE : fatal error U1077: 'meson setup --prefix C:\code\venv --pkg-config-path C:\code\venv\lib\pkgconfig;C:\code\lib\pkgconfig;C:\vcpkg\installed\x64-windows\lib\pkgconfig --buildtype release --debug -Db_lto=true --bindir=Scripts --libdir=Lib --includedir=Include -Db_vscrt=md --backend=vs2022 -Dtests=false C:\code\external\pkgconf external\pkgconf\builddir' : return code '0x1'

I rmtree the build dir....

meson setup --prefix C:\code\venv --pkg-config-path C:\code\venv\lib\pkgconfig;C:\code\lib\pkgconfig;C:\vcpkg\installed\x64-windows\lib\pkgconfig --buildtype release --debug -Db_lto=true --bindir=Scripts --libdir=Lib --includedir=Include -Db_vscrt=md --backend=vs2022 -Drpath=true C:\code\external\ external\builddir

and now no problem to rebuild from start....

[dcbaker]

I had a patch for that at one point, I wonder what happend to it...

I'm really concerned this is just us doing something dumb. Does this cause the same bug:

meson setup builddir
meson setup builddir --wipe  # or possibly just --reconfigure

[rlavarec-gpsw]

With Meson 1.4.0 The code to rebuild pkgconf is failing

meson setup --prefix C:\code\venv --pkg-config-path C:\code\venv\lib\pkgconfig;C:\vcpkg\installed\x64-windows\lib\pkgconfig --buildtype release --debug -Db_lto=true --bindir=Scripts --libdir=Lib --includedir=Include -Db_vscrt=md --backend=vs2022 -Dtests=false C:\code\external\pkgconf external\pkgconf\builddir

ERROR: Unknown options: "b_lto"

If I do a

meson setup --wipe C:\code\external\pkgconf C:\code\external\pkgconf\builddir\

All is ok "going ok"

If I restart

meson setup --prefix C:\code\venv --pkg-config-path C:\code\venv\lib\pkgconfig;C:\vcpkg\installed\x64-windows\lib\pkgconfig --buildtype release --debug -Db_lto=true --bindir=Scripts --libdir=Lib --includedir=Include -Db_vscrt=md --backend=vs2022 -Dtests=false C:\code\external\pkgconf external\pkgconf\builddir

Directory already configured.

Just run your build command (e.g. ninja) and Meson will regenerate as necessary.
Run "meson setup --reconfigure to force Meson to regenerate.

If build failures persist, run "meson setup --wipe" to rebuild from scratch
using the same options as passed when configuring the build.

ERROR: Unknown options: "b_lto"

I do not reproduce it easily or all the time. (I do not look for it) When it is stuck, we got a wipe method we are using to remove all the builddir with rmtree. And it is working again from "blank".

[rlavarec-gpsw]

To me there is something wrong in the code telling:

ERROR: Unknown options: "b_lto"

But for sure it is a known option !

[rlavarec-gpsw]

Could you please merge the fix of the bug ? I do not think it will impair anything except fixing our bug. All checks are green.

[rlavarec-gpsw]

@dcbaker @dnicolodi Any news ?

I think the patch is pretty small and pretty safe. All CI is green.

You should never get: ERROR: Unknown options: "b_lto"

So It is just checking the option is inside the list of base_options and not throw an unknown option error for that.

[rlavarec-gpsw]

@dcbaker @dnicolodi can it be merged ?

[dnicolodi]

I still don't see any test added to verify that this does what it is supposed to do and to ensure that this does not regress again.

[rlavarec-gpsw]

@dnicolodi Added a test with "-Db_lto=true"

[rlavarec-gpsw]

Hi, @dcbaker @dnicolodi can it be merged ?

[rlavarec-gpsw]

Hi, @dcbaker @dnicolodi can it be merged ? Sorry to insist about it. It is a "just" a small bug fix, but blocking us to use the main of the project. I know you got a lot of review to do. Thanks a lot for your contribution

[rlavarec-gpsw]

Hello, @dcbaker @dnicolodi @bruchar1 @eli-schwartz @jpakkane ?

Just to notice it But this code is mainly a copy paste of the code inside

def set_default_options(self, default_options: T.MutableMapping[OptionKey, str], subproject: str, env: 'Environment') -> None:

Doing exactly the same thing..... minus the comment I didn't add again

...
          from .compilers import base_options
...
            if k.type == OptionType.BASE and k.as_root() in base_options:
                # set_options will report unknown base options
                continue
...

I do not see why this PR is blocked. Tests already exist.. All CI is green... Code is the same in the function next to it.... I don't want to take too much of the time of anyone including me on this minor but blocking bug. But we would like to resume to use the main repo of meson. Thanks a lot for all the job you are doing for the community.

[eli-schwartz]

Doing exactly the same thing..... minus the comment I didn't add again

I haven't refreshed my memory on what this section of the code does. But "set_options will report unknown base options" -- this implies that the function you're modifying here is supposed to report this as an unknown option.

A test case for this would be nice.