Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for the TASKING compiler family, and its MIL linking feature #12342

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

gerioldman
Copy link

This PR adds support for the TASKING compiler family, and its MIL linking feature as mentioned in #11866.

mesonbuild/compilers/c.py Fixed Show fixed Hide fixed
mesonbuild/compilers/c.py Fixed Show fixed Hide fixed
mesonbuild/compilers/c.py Fixed Show fixed Hide fixed
mesonbuild/compilers/c.py Fixed Show fixed Hide fixed
mesonbuild/compilers/c.py Fixed Show fixed Hide fixed
mesonbuild/compilers/c.py Fixed Show fixed Hide fixed
mesonbuild/compilers/c.py Fixed Show fixed Hide fixed
mesonbuild/compilers/c.py Fixed Show fixed Hide fixed
mesonbuild/compilers/c.py Fixed Show fixed Hide fixed
mesonbuild/compilers/c.py Fixed Show fixed Hide fixed
@tristan957
Copy link
Contributor

Can you squash your commits where appropriate? Git history isn't making sense.

@gerioldman
Copy link
Author

I'll wait for the checks to finish, after that I will try

1 similar comment
@gerioldman
Copy link
Author

I'll wait for the checks to finish, after that I will try

@gerioldman
Copy link
Author

@tristan957 Is it better now?

@tristan957
Copy link
Contributor

Here are the commits I envision:

  • Add tricore to CPU families
  • Add TASKING compiler support

Should there be any other reason for more commits?

@gerioldman gerioldman force-pushed the TaskingCCompiler branch 2 times, most recently from 9838cdf to 2817c5f Compare October 12, 2023 13:14
@gerioldman
Copy link
Author

Fair enough, done :)

@gerioldman gerioldman force-pushed the TaskingCCompiler branch 3 times, most recently from 885a87b to 7f3a06e Compare December 21, 2023 23:23
Copy link
Member

@bruchar1 bruchar1 left a comment

Choose a reason for hiding this comment

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

I know nothing about those compilers, but here are some general comments.

docs/markdown/Builtin-options.md Outdated Show resolved Hide resolved
else:
raise EnvironmentException('Failed to detect linker for TASKING VX-toolset compiler. Please update your cross file(s).')

tasking_ver_match = re.search(r'v(\d+)\.(\d+)r(\d+) Build (\d+)', err)
Copy link
Member

Choose a reason for hiding this comment

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

Please use [0-9] instead of \d

return cls(
ccache, compiler, tasking_version, for_machine, is_cross, info,
exe_wrap, full_version=full_version, linker=linker)
# TODO add detection logic here
Copy link
Member

Choose a reason for hiding this comment

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

Will you do it?

Copy link
Author

Choose a reason for hiding this comment

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

I think I have left that there by mistake, I'll take that comment out.

mesonbuild/compilers/mixins/tasking.py Outdated Show resolved Hide resolved
Comment on lines 32 to 31
tasking_buildtype_args: T.Dict[str, T.List[str]] = {
'plain': [],
'debug': ['-g3', '-O0'],
'debugoptimized': ['-g3', '-O2'],
'release': ['-O3'],
'minsize': ['-O3', '--tradeoff=4'],
'custom': []
}
Copy link
Member

Choose a reason for hiding this comment

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

Please use optimization and debug args instead of buildtype. -g3 is already in debug args. Other options are for optimization.

Comment on lines 709 to 710
rules += [f"{rule}{ext}" for rule in [self.get_compiler_rule_name('tasking_mil_compile', compiler.for_machine)]
for ext in ['', '_RSP']]
Copy link
Member

Choose a reason for hiding this comment

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

This line is overcomplicated. Please imbricated for loops instead. Not sure why you iterate through a one-item list.

mesonbuild/backend/ninjabackend.py Outdated Show resolved Hide resolved
mesonbuild/backend/ninjabackend.py Outdated Show resolved Hide resolved
@jpakkane
Copy link
Member

The MIL thing is a bit problematic as it is unique to this compiler and thus makes it a notable maintenance burden (as we don't have access to said compiler at all). All other compilers that I know of do this by outputting plain .o files with extra data in them (this is how link-time optimization works in e.g. Clang et al).

Is there any data on how effective it is compared to plain unity builds? That is, if people could get the same performance using builtin unity support rather than this very toolchain specific thingy, would we need to support MIL at all?

@gerioldman
Copy link
Author

Unfortunately, I do not have any performance data. At first I didn't want to implement the MIL linking for the very reason you mention, but I was unable to make unity build work for the project I was converting to Meson due to some conditional compilation pattern used in almost all files, which pull in a specified part generated headers. With MIL linking, this is not a problem, files are compiled in an identical manner until this MIL intermediate language part.

Not sure how to approach the fact that the compiler is not available for use, the best that I could think of was writing a dummy CLI emulation of the compiler, so some tests could run at the very least.

@afahmy-ANGENG
Copy link

Thanks for the TASKING Compiler support PR, I successfully used it with TASKING v6.3r1 to build firmware for Infineon TriCore TC375. The output hex file was flashed and it runs successfully on target.

@tsetsong
Copy link

tsetsong commented Jan 23, 2024

Hi, Is it possible to share sample files or configurations required to set up a build directory for Tasking Tricore please? Thank you.

The cross_build.txt file I am using is attached.
cross_build.txt

I ran command :

meson setup --cross-file cross_build.ini builddir

But I am getting errors :

Source dir: D:\work\buildsystem\meson_crossbuild
Build dir: D:\work\buildsystem\meson_crossbuild\builddir
Build type: cross build
Project name: tc_hello
Project version: 1.0
Activating VS 17.8.4
C compiler for the host machine: d:/Bitbucket/Tools_Inv_HMC_IDM\Compiler\ctc\bin\cctc.exe (cctc 6.3.1.19041558)
Traceback (most recent call last):
  File "c:\Python310\lib\site-packages\meson-1.2.99-py3.10.egg\mesonbuild\mesonmain.py", line 194, in run
    return options.run_func(options)
... snip ...
  File "c:\Python310\lib\site-packages\meson-1.2.99-py3.10.egg\mesonbuild\interpreter\interpreter.py", line 1549, in add_languages_for
    mlog.bold(' '.join(comp.linker.get_exelist())), comp.linker.id, comp.linker.version)
  File "c:\Python310\lib\site-packages\meson-1.2.99-py3.10.egg\mesonbuild\linkers\linkers.py", line 160, in get_exelist
    return self.exelist.copy()
AttributeError: 'NoneType' object has no attribute 'copy'

meson.build:1:0: ERROR: Unhandled python exception

    This is a Meson bug and should be reported!

One other question, I don't understand why I am getting :

Activating VS 17.8.4

Is there something I missed in my configurations ? I am not expecting my Visual Studio installation to be used in this build.

Thank you.

@gerioldman
Copy link
Author

This should work, however, I did not implement support for C++. Not sure why it wants VS, for good measure I would pass in --wipe when configuring.

[constants]
tools_folder = 'd:/Bitbucket/Tools_Inv_HMC_IDM'
compiler_path = tools_folder / 'Compiler'
[built-in options]
c_args = ['-D__CPU__=tc37x', '-D__CPU_TC37X__','-D_TASKING_C_TRICORE_','-g','--align=4','--iso=99']
[project options]
[binaries]
c = compiler_path / 'ctc' / 'bin' / 'cctc.exe'
#cpp = compiler_path / 'ctc' / 'bin' / 'cctc.exe' I did not implement support for C++, it would be cptc.exe
ld = compiler_path / 'ctc' / 'bin' / 'cctc.exe'
ar = compiler_path / 'ctc' / 'bin' / 'artc.exe'
as = compiler_path / 'ctc' / 'bin' / 'cctc.exe'
exe_wrapper = 'meson_exe_wrapper.sh'

[properties]

[host_machine]
system = 'none'
#subsystem = ''
kernel = 'none'
cpu_family = 'tricore'
cpu = 'TC377'
endian = 'little'

@tsetsong
Copy link

tsetsong commented Jan 24, 2024

Hi @gerioldman,

Thank you for your reply.
I tried the settings you gave but it did not help. I am still getting the same error.

I will continue to look into this as my team is trying to switch to meson/ninja. We are on a gmake based build system currently.
I think the VS 17.8.4 may be suspicious. I do have VS (Visual Studio) and VS build Tools installed but they shouldn't be used or detected in this case.

update :
I ported meson and my project to a computer without a VS (Visual Studio) installation, and I got the following :

WARNING: Failed to activate VS environment: Could not find C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe
But I am still getting the same error as in the previous post.

regards,
TseTsong, Teo

@afahmy-ANGENG
Copy link

Hi @tsetsong
Are you sure you are running this PR meson and not a previous version of it ?
Try running it as:
<PR checkout location>/meson.py setup --cross-file cross_build.ini builddir

@tsetsong
Copy link

tsetsong commented Jan 24, 2024

Hi @tsetsong Are you sure you are running this PR meson and not a previous version of it ? Try running it as: <PR checkout location>/meson.py setup --cross-file cross_build.ini builddir

Thank you @afahmy-ANGENG for your reply.
I should have attached details of the version of the repo I am using.

I work on a Windows 10 machine.

Here are repository details and how I get the error :

D:\work\mesontasking>git log -1
commit 4f44bbea6d81b059cd5d00fc3b976d5f034d0ba4 (HEAD -> TaskingCCompiler, origin/TaskingCCompiler)
Author: Krisztián Gergő <[email protected]>
Date:   Fri Dec 22 20:30:04 2023 +0100

    Update mesonbuild/backend/ninjabackend.py

    Co-authored-by: Charles Brunet <[email protected]>

D:\work\mesontasking>git branch
* TaskingCCompiler
  master

D:\work\mesontasking>git remote
origin

D:\work\mesontasking>git remote -v
origin  https://github.com/gerioldman/meson.git (fetch)
origin  https://github.com/gerioldman/meson.git (push)

And I built and installed my meson like this :

cd d:\work\mesontasking
python setup.py build
python setup.py install

My python installation is at

C:\Program Files\Python311

D:\work\mesontasking>python --version
Python 3.11.6

My Ninja is at :
c:\Ninja

According to your instructions, I have done the following from my project folder :

d:\work\mesontasking>meson.py setup --cross-file cross_build.txt --wipe builddir

The output is the same :

The Meson build system
Version: 1.2.99
Source dir: D:\work\meson_crossbuild
Build dir: D:\work\meson_crossbuild\builddir
Build type: cross build
Project name: tc_hello
Project version: 1.0
WARNING: Failed to activate VS environment: Could not find C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe
C compiler for the host machine: d:/Bitbucket/Tools_Inv_HMC_IDM\Compiler\ctc\bin\cctc.exe (cctc 6.3.1.19041558)
Traceback (most recent call last):
  File "D:\work\mesontasking\mesonbuild\mesonmain.py", line 194, in run
    return options.run_func(options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\msetup.py", line 356, in run
    app.generate()
  File "D:\work\mesontasking\mesonbuild\msetup.py", line 179, in generate
    return self._generate(env, capture, vslite_ctx)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\msetup.py", line 201, in _generate
    intr = interpreter.Interpreter(b, user_defined_options=user_defined_options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\interpreter\interpreter.py", line 331, in __init__
    self.parse_project()
  File "D:\work\mesontasking\mesonbuild\interpreterbase\interpreterbase.py", line 132, in parse_project
    self.evaluate_codeblock(self.ast, end=1)
  File "D:\work\mesontasking\mesonbuild\interpreterbase\interpreterbase.py", line 188, in evaluate_codeblock
    raise e
  File "D:\work\mesontasking\mesonbuild\interpreterbase\interpreterbase.py", line 180, in evaluate_codeblock
    self.evaluate_statement(cur)
  File "D:\work\mesontasking\mesonbuild\interpreterbase\interpreterbase.py", line 194, in evaluate_statement
    return self.function_call(cur)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\interpreterbase\interpreterbase.py", line 520, in function_call
    res = func(node, func_args, kwargs)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\interpreterbase\decorators.py", line 260, in wrapper
    return f(*nargs, **wrapped_kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\interpreterbase\decorators.py", line 579, in wrapper
    return f(*wrapped_args, **wrapped_kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\interpreter\interpreter.py", line 1308, in func_project
    self.add_languages(proj_langs, True, MachineChoice.HOST)
  File "D:\work\mesontasking\mesonbuild\interpreter\interpreter.py", line 1476, in add_languages
    success = self.add_languages_for(args, required, for_machine)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\interpreter\interpreter.py", line 1549, in add_languages_for
    mlog.bold(' '.join(comp.linker.get_exelist())), comp.linker.id, comp.linker.version)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\work\mesontasking\mesonbuild\linkers\linkers.py", line 160, in get_exelist
    return self.exelist.copy()
           ^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'copy'

meson.build:1:0: ERROR: Unhandled python exception

@tsetsong
Copy link

tsetsong commented Jan 26, 2024

Hi all,

Update :

The line :

WARNING: Failed to activate VS environment: ...

or

Activating VS 17.8.4

Will not show if you have gcc installed. The section of meson code responsible for this is in Interpreter.py :

.. snip ...
    if not force:
        if shutil.which('cc'):
            return False
        if shutil.which('gcc'):
            return False
        if shutil.which('clang'):
            return False
        if shutil.which('clang-cl'):
            return False

It is possible to follow the instructions to install MinGW here :
https://dev.to/gamegods3/how-to-install-gcc-in-windows-10-the-easier-way-422j
and include the path to gcc.exe in PATH.

This will allow the shutil.which('gcc') to be True, and the function will return with 'False'.

However, this does not solve the original problem of the generation crash. I am still looking into this.

@tsetsong
Copy link

tsetsong commented Jan 26, 2024

Hi,

Update :

I am now able to generate my build folder.

An additional modification is needed in my cross_build.txt file.

The

ld = compiler_path / 'ctc' / 'bin' / 'cctc.exe'

entry needs to be specified as :

c_ld = compiler_path / 'ctc' / 'bin' / 'cctc.exe'

I will proceed with compilation and porting and will report any other findings here as well.

Here is the stdout :

d:\work\buildsystem\meson_crossbuild>meson.exe setup --cross-file cross_build.txt --wipe builddir
The Meson build system
Version: 1.2.99
Source dir: D:\work\buildsystem\meson_crossbuild
Build dir: D:\work\buildsystem\meson_crossbuild\builddir
Build type: cross build
Project name: tc_hello
Project version: 1.0
WARNING: Failed to activate VS environment: Could not find C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe
C compiler for the host machine: d:/Bitbucket/Tools_Inv_HMC_IDM\Compiler\ctc\bin\cctc.exe (cctc 6.3.1.19041558)
C linker for the host machine: d:/Bitbucket/Tools_Inv_HMC_IDM\Compiler\ctc\bin\cctc.exe ltc 6.3.1.19041558
Compiler for language c for the build machine not found.
Build machine cpu family: x86_64
Build machine cpu: x86_64
Host machine cpu family: tricore
Host machine cpu: TC377
Target machine cpu family: tricore
Target machine cpu: TC377
Build targets in project: 1

tc_hello 1.0

  User defined options
    Cross files: cross_build.txt

Found ninja-1.11.1 at c:\ninja\ninja.EXE
WARNING: Cross file does not specify strip binary, result will not be stripped.
WARNING: Cross file does not specify strip binary, result will not be stripped.

I have also attached the build setup log (meson-log.txt file for reference.
meson-log.txt

Cross_build file :
cross_build.txt

Command ran :

meson.exe setup --cross-file cross_build.txt --wipe builddir

I notice in the meson-log.txt file that the archiver is used instead of the linker when detecting linker :

Detecting linker via: `d:/Bitbucket/Tools_Inv_HMC_IDM\Compiler\ctc\bin\artc.exe --version` -> 0
stderr:
TASKING VX-toolset for TriCore: ELF archiver   v6.3r1 Build 19041558
Copyright 2002-2019 TASKING BV

How come ?

Copy link
Member

@dcbaker dcbaker left a comment

Choose a reason for hiding this comment

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

Sorry it's taken me so long to look at this. In general this all looks good. There's some thigns I think we can clean up here, but otherwise this looks fine from a code point of view.

mesonbuild/backend/ninjabackend.py Outdated Show resolved Hide resolved
@@ -402,7 +405,7 @@ def write(self, outfile):
outfile.write(line)

if use_rspfile:
if self.rule.rspfile_quote_style is RSPFileSyntax.MSVC:
if self.rule.rspfile_quote_style is RSPFileSyntax.MSVC or self.rule.rspfile_quote_style is RSPFileSyntax.TASKING:
Copy link
Member

Choose a reason for hiding this comment

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

Same here, use the in {...} syntax

Comment on lines 1066 to 1073
try:
key = OptionKey('b_tasking_mil_link')
if key in target.compilers['c'].base_options and target.get_option(key):
final_obj_list = self.generate_mil_link(target, obj_list)
else:
final_obj_list = obj_list
except KeyError:
final_obj_list = obj_list
Copy link
Member

Choose a reason for hiding this comment

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

You'll hit that exception when you don't have a C compiler, but no other cases it looks like. Can we handle that without a try/except, since that's not unexpected at all?

Comment on lines 3071 to 3079
try:
key = OptionKey('b_tasking_mil_link')
if key in target.compilers['c'].base_options and target.get_option(key) and src.endswith('.c'):
if obj_basename.endswith('.o'):
obj_basename = obj_basename[:-1] + 'mil'
else:
obj_basename = obj_basename[:-3] + 'mil'
except KeyError:
pass
Copy link
Member

Choose a reason for hiding this comment

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

This looks like the same case, where the missing c compiler is the issue.

Copy link
Author

Choose a reason for hiding this comment

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

The problem is that the target might not contain the built-in option, so it end ups throwing a KeyError. I've added a check if the target even contains it. Do you know any better solution? I've tried modifying the get_option call to fall back to the base_option var in the compilers.py file, but that had some CI failures.

But yes, the C compiler not being present is another problem, I've added a check for it.

Copy link
Author

Choose a reason for hiding this comment

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

Oh, main has the same CI failures, maybe the base_option fallback was not the culprit then.

mesonbuild/backend/ninjabackend.py Outdated Show resolved Hide resolved
if 'PCP' in err:
return linkers.TaskingPCPStaticLinker(linker)
if 'MCS' in err:
return linkers.TaskingMCSStaticLinker(linker)
Copy link
Member

Choose a reason for hiding this comment

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

Do you actually want to fall through here and end up with the system linker, link.exe or ar?

mesonbuild/compilers/mixins/tasking.py Outdated Show resolved Hide resolved
mesonbuild/linkers/linkers.py Show resolved Hide resolved
mesonbuild/backend/ninjabackend.py Outdated Show resolved Hide resolved
mesonbuild/backend/ninjabackend.py Outdated Show resolved Hide resolved
@dcbaker
Copy link
Member

dcbaker commented Jan 26, 2024

I notice in the meson-log.txt file that the archiver is used instead of the linker when detecting linker :

Detecting linker via: `d:/Bitbucket/Tools_Inv_HMC_IDM\Compiler\ctc\bin\artc.exe --version` -> 0 stderr: TASKING VX-toolset for TriCore: ELF archiver v6.3r1 Build 19041558 Copyright 2002-2019 TASKING BV

How come ?

That looks like a Meson bug, we have the same message for both the archiver and dynamic linker... I'll send a patch for that.

edit: #12784

@gerioldman gerioldman force-pushed the TaskingCCompiler branch 2 times, most recently from 2f9c728 to 8603a50 Compare August 24, 2024 23:59
@jpakkane
Copy link
Member

We try really hard to avoid adding new options without a good reason (because otherwise you have 1000+ options in the blink of an eye). Since this is "sort of" a link time optimization, would it be possible to make the code use the b_lto option instead of its own?

# This is a bit clever, for mypy we pretend that these mixins descend from
# Compiler, so we get all of the methods and attributes defined for us, but
# for runtime we make them descend from object (which all classes normally
# do). This gives up DRYer type checking, with no runtime impact
Copy link
Member

Choose a reason for hiding this comment

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

I think there is a typo: gives up should be gives us.

Copy link
Author

Choose a reason for hiding this comment

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

Corrected it.

@gerioldman
Copy link
Author

We try really hard to avoid adding new options without a good reason (because otherwise you have 1000+ options in the blink of an eye). Since this is "sort of" a link time optimization, would it be possible to make the code use the b_lto option instead of its own?

I think that makes sense, I'll try to do that. Do you thing that 'b_lto' fits for the static library part of the MIL linking? What I mean is that right now, tasking_mil_link is possible to set for static libraries. This has the effect of LTO inside the library, but not with other code parts. However, it is possible to create MIL libraries, which behave as static libs, but still benefit from LTO at the actual link stage.

Maybe a combination of prelink kward and b_lto could be used?

@gerioldman
Copy link
Author

gerioldman commented Aug 26, 2024

The MIL thing is a bit problematic as it is unique to this compiler and thus makes it a notable maintenance burden (as we don't have access to said compiler at all). All other compilers that I know of do this by outputting plain .o files with extra data in them (this is how link-time optimization works in e.g. Clang et al).

I've just learned this, but there is a free, non-commercial version of the compiler bundled inside the Aurix Development Studio by Infineon. The compiler cannot be used outside the IDE though, a Meson build would have to be setup inside Eclipse. I am open to create a debug project, so you can try around with the compiler if any issues arise.

@gerioldman gerioldman force-pushed the TaskingCCompiler branch 5 times, most recently from cc15591 to 02d07a7 Compare August 28, 2024 21:36
@gerioldman gerioldman force-pushed the TaskingCCompiler branch 6 times, most recently from 6159668 to ec98f09 Compare September 10, 2024 21:22
@jpakkane jpakkane added this to the 1.7 milestone Oct 12, 2024
@jpakkane
Copy link
Member

jpakkane commented Nov 1, 2024

I think that makes sense, I'll try to do that. Do you thing that 'b_lto' fits for the static library part of the MIL linking? What I mean is that right now, tasking_mil_link is possible to set for static libraries. This has the effect of LTO inside the library, but not with other code parts. However, it is possible to create MIL libraries, which behave as static libs, but still benefit from LTO at the actual link stage.

Maybe a combination of prelink kward and b_lto could be used?

What happens if you use both at the same time?

Based on this description "LTO inside a static lib" is pretty much the same as prelinking whereas "LTO over mutliple libraries" is what Meson calls regular LTO. So hooking it up to those would make logical sense.

@gerioldman
Copy link
Author

There should be three possible results:

  • regular compilation and linking
  • LTO over multiple libraries
  • LTO inside library

I think prelink should take priorioty, someone might set LTO for the whole project, but prelinking can only be set per target. Based on that:
No LTO and no prelink: regular compilation
LTO and no prelink: LTO over multiple libraries
No LTO or LTO and prelink: LTO inside static library

What do you think?

@@ -25,6 +25,7 @@
from .. import mesonlib
from .. import mlog
from ..compilers import LANGUAGES_USING_LDFLAGS, detect
from ..utils.universal import get_compiler_for_source

Check failure

Code scanning / CodeQL

Module-level cyclic import Error

'get_compiler_for_source' may not be defined if module
mesonbuild.utils.universal
is imported before module
mesonbuild.backend.backends
, as the
definition
of get_compiler_for_source occurs after the cyclic
import
of mesonbuild.backend.backends.
'get_compiler_for_source' may not be defined if module
mesonbuild.utils.universal
is imported before module
mesonbuild.backend.backends
, as the
definition
of get_compiler_for_source occurs after the cyclic
import
of mesonbuild.backend.backends.
'get_compiler_for_source' may not be defined if module
mesonbuild.utils.universal
is imported before module
mesonbuild.backend.backends
, as the
definition
of get_compiler_for_source occurs after the cyclic
import
of mesonbuild.backend.backends.
'get_compiler_for_source' may not be defined if module
mesonbuild.utils.universal
is imported before module
mesonbuild.backend.backends
, as the
definition
of get_compiler_for_source occurs after the cyclic
import
of mesonbuild.backend.backends.
'get_compiler_for_source' may not be defined if module
mesonbuild.utils.universal
is imported before module
mesonbuild.backend.backends
, as the
definition
of get_compiler_for_source occurs after the cyclic
import
of mesonbuild.backend.backends.
'get_compiler_for_source' may not be defined if module
mesonbuild.utils.universal
is imported before module
mesonbuild.backend.backends
, as the
definition
of get_compiler_for_source occurs after the cyclic
import
of mesonbuild.backend.backends.
'get_compiler_for_source' may not be defined if module
mesonbuild.utils.universal
is imported before module
mesonbuild.backend.backends
, as the
definition
of get_compiler_for_source occurs after the cyclic
import
of mesonbuild.backend.backends.
from .mixins.emscripten import EmscriptenMixin
from .mixins.metrowerks import MetrowerksCompiler
from .mixins.metrowerks import mwccarm_instruction_set_args, mwcceppc_instruction_set_args
from .mixins.tasking import TaskingCompiler

Check failure

Code scanning / CodeQL

Module-level cyclic import Error

'TaskingCompiler' may not be defined if module
mesonbuild.compilers.mixins.tasking
is imported before module
mesonbuild.compilers.c
, as the
definition
of TaskingCompiler occurs after the cyclic
import
of mesonbuild.compilers.c.
'TaskingCompiler' may not be defined if module
mesonbuild.compilers.mixins.tasking
is imported before module
mesonbuild.compilers.c
, as the
definition
of TaskingCompiler occurs after the cyclic
import
of mesonbuild.compilers.c.
'TaskingCompiler' may not be defined if module
mesonbuild.compilers.mixins.tasking
is imported before module
mesonbuild.compilers.c
, as the
definition
of TaskingCompiler occurs after the cyclic
import
of mesonbuild.compilers.c.
'TaskingCompiler' may not be defined if module
mesonbuild.compilers.mixins.tasking
is imported before module
mesonbuild.compilers.c
, as the
definition
of TaskingCompiler occurs after the cyclic
import
of mesonbuild.compilers.c.
@@ -9,6 +9,7 @@
from ...mesonlib import MesonException

if T.TYPE_CHECKING:
from ...build import BuildTarget

Check failure

Code scanning / CodeQL

Module-level cyclic import Error

'BuildTarget' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.apple
, as the
definition
of BuildTarget occurs after the cyclic
import
of mesonbuild.compilers.mixins.apple.
'BuildTarget' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.apple
, as the
definition
of BuildTarget occurs after the cyclic
import
of mesonbuild.compilers.mixins.apple.
'BuildTarget' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.apple
, as the
definition
of BuildTarget occurs after the cyclic
import
of mesonbuild.compilers.mixins.apple.
from .gnu import gnu_optimization_args
from ...mesonlib import Popen_safe
from ...options import OptionKey
from ...build import BuildTarget

Check failure

Code scanning / CodeQL

Module-level cyclic import Error

'BuildTarget' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.elbrus
, as the
definition
of BuildTarget occurs after the cyclic
import
of mesonbuild.compilers.mixins.elbrus.
'BuildTarget' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.elbrus
, as the
definition
of BuildTarget occurs after the cyclic
import
of mesonbuild.compilers.mixins.elbrus.
'BuildTarget' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.elbrus
, as the
definition
of BuildTarget occurs after the cyclic
import
of mesonbuild.compilers.mixins.elbrus.
@@ -17,6 +17,7 @@
from ... import mesonlib
from ... import mlog
from ...options import OptionKey
from ...build import BuildTarget

Check failure

Code scanning / CodeQL

Module-level cyclic import Error

'BuildTarget' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.gnu
, as the
definition
of BuildTarget occurs after the cyclic
import
of mesonbuild.compilers.mixins.gnu.
'BuildTarget' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.gnu
, as the
definition
of BuildTarget occurs after the cyclic
import
of mesonbuild.compilers.mixins.gnu.
'BuildTarget' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.gnu
, as the
definition
of BuildTarget occurs after the cyclic
import
of mesonbuild.compilers.mixins.gnu.
import typing as T

from ...mesonlib import EnvironmentException, File
from ...options import OptionKey

Check failure

Code scanning / CodeQL

Module-level cyclic import Error

'OptionKey' may not be defined if module
mesonbuild.options
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of OptionKey occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'OptionKey' may not be defined if module
mesonbuild.options
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of OptionKey occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.

from ...mesonlib import EnvironmentException, File
from ...options import OptionKey
from ...build import BuildTarget, StaticLibrary

Check failure

Code scanning / CodeQL

Module-level cyclic import Error

'BuildTarget' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of BuildTarget occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'BuildTarget' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of BuildTarget occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'BuildTarget' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of BuildTarget occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.

from ...mesonlib import EnvironmentException, File
from ...options import OptionKey
from ...build import BuildTarget, StaticLibrary

Check failure

Code scanning / CodeQL

Module-level cyclic import Error

'StaticLibrary' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of StaticLibrary occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'StaticLibrary' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of StaticLibrary occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'StaticLibrary' may not be defined if module
mesonbuild.build
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of StaticLibrary occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
from ...compilers import lang_suffixes

if T.TYPE_CHECKING:
from ...compilers.compilers import Compiler

Check failure

Code scanning / CodeQL

Module-level cyclic import Error

'Compiler' may not be defined if module
mesonbuild.compilers.compilers
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of Compiler occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'Compiler' may not be defined if module
mesonbuild.compilers.compilers
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of Compiler occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'Compiler' may not be defined if module
mesonbuild.compilers.compilers
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of Compiler occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'Compiler' may not be defined if module
mesonbuild.compilers.compilers
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of Compiler occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'Compiler' may not be defined if module
mesonbuild.compilers.compilers
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of Compiler occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'Compiler' may not be defined if module
mesonbuild.compilers.compilers
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of Compiler occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'Compiler' may not be defined if module
mesonbuild.compilers.compilers
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of Compiler occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'Compiler' may not be defined if module
mesonbuild.compilers.compilers
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of Compiler occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'Compiler' may not be defined if module
mesonbuild.compilers.compilers
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of Compiler occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'Compiler' may not be defined if module
mesonbuild.compilers.compilers
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of Compiler occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'Compiler' may not be defined if module
mesonbuild.compilers.compilers
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of Compiler occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'Compiler' may not be defined if module
mesonbuild.compilers.compilers
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of Compiler occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
'Compiler' may not be defined if module
mesonbuild.compilers.compilers
is imported before module
mesonbuild.compilers.mixins.tasking
, as the
definition
of Compiler occurs after the cyclic
import
of mesonbuild.compilers.mixins.tasking.
@gerioldman gerioldman force-pushed the TaskingCCompiler branch 2 times, most recently from e174630 to e965caa Compare November 10, 2024 22:17
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.

9 participants