-
-
Notifications
You must be signed in to change notification settings - Fork 773
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
.cmake Adaptor (detection modules)? #83
Comments
xmake also provide these features, so I don't intend to wrap them. |
Compiler detection of xmake is perfect "Package search" is working on the way. You could have a look branch Thanks for caring 😃 |
Thanks for reply. I'm just a little bit worried that there might be a lot more to do than you think. Take C++ as an example, we may need:
Supporting |
I'd like to have a quick look into it this week |
@htfy96 You can use for example: option("test")
add_define_if_ok("ENABLE_TEST")
add_ctypes("wchar_t")
add_cincludes("setjmp.h")
add_cfuncs("sigsetjmp", "setjmp")
-- add_cfuncs("sigsetjmp((void*)0, 0)")
-- add_cfuncs("sigsetjmp{int a = 0; sigsetjmp((void*)a, a);}")
add_links("pthread")
target("demo")
add_options("test")
... It will detect The |
And you can add If compiler does not support these flags, It will ignore it automatically. |
xmake will detect msvc on windows by default automatically. If you want to use other compiler, you can set it manually. for example: $ xmake f --cc=clang --cxx=clang --ld=clang
$ xmake And it will detect clang, gcc, .. on linux/macos. |
IIUC, according to your example
Actually I'm more willing to see something like I'm referring to Clang/C2 frontend of MSVC. Take a look into CMake's patch set, and you'll find that checking |
@htfy96 Yes, xmake currently has no plan for builtin feature detection based on compiler version.
This is only configured and detected once
This is not a problem, the detection rules can be improved more flexibly.
xmake takes the gcc flags as the standard and will map to other compiler flags smartly. So these flags ( About #if (defined(__has_feature) && __has_feature(address_sanitizer)) || \
defined(__SANITIZE_ADDRESS__)
...
#endif |
@waruqi
This doesn't seem to work. Older compilers do not support |
Now for flags adding, xmake uses gcc flags mapping Advantage:
Disadvantage:
I agree with generic flags like what you said as a second choice |
And consider this case: user specified The initiative of this issue is that compatibility/detection is extremely difficult. Manual checking could be very time-consuming and complicated. It is difficult to implement your own compiler database like |
@htfy96
|
If has not sanitize support, |
Therefore, even using the CMake database does not guarantee all compilers, versions and archs. And this need instant update compiler database to detect new features and versions. The most stable way is that try to compile it to detect it. |
@waruqi The Moreover, some features cannot be detected at compile-time without compiler mapping. For example: |
👍 @waruqi
You're right @htfy96
xmake does you say, compile with it during configuration to check whether a flag is available @htfy96
Great example 👍 @htfy96 Maybe best solution is
|
You can define one
You also can use option to detect flags. Although I don't support it now, I'll improve it. option("fsanitize_address")
add_cxflags("-fsanitize=address") <-- I'll improve it here.
add_ldflags("-fsanitize=address") |
I've detected it in add_cfunc("API", "readline", nil, {"readline/readline.h"}, "readline") |
But many vendors will modify the compiler (for some cross-toolchains), even the compiler with the same version does not guarantee that many implementations exist or not. So there is the same problem with the database. |
Yep @waruqi but this is just a example that not so exact and other code snippets could be used |
Database is not no use at all! @waruqi |
@titansnow @htfy96 So I'm still more inclined to use compile detection. Perhaps xmake's detection is not flexible enough, but I will improve it. |
@waruqi Thanks for your effort. It would be piles of work to implement proper compiler detection. |
@htfy96 😄 |
Sorry, but for me there's still trouble to implement |
@titansnow I will implement it in last these days. |
@htfy96 I have quickly looked through I found that your idea is great 👍 Many things are useful like In fact trying to link with Qt in xmake might be troublesome or I don't get the way? @waruqi And If In this way, I agree with @htfy96 My option is on-fly detection is the first hand, off-fly data & script is the second hand This idea should be minded @waruqi Does you have a preliminary way to implement the adapter, @htfy96 ? Or could you do some work on this and finally give a PR? |
Git is a necessary component for xmake also support tool detection and only for internal detection. In the future I will provide public interfaces to find tools like
Xmake has its own design pattern, not depend on
This is really a good feature. I will improve |
@htfy96 I have implemented -- define option for detecting constexpr feature
option("constexpr")
set_languages("cxx14")
add_defines_if_ok("CONSTEXPR_ENABLE")
add_cxxsnippet("constexpr", "constexpr int f(int x) { int sum=0; for (int i=0; i<=x; ++i) sum += i; return sum; } constexpr int x = f(5); static_assert(x == 15);")
-- add target
target("test")
-- set kind
set_kind("binary")
-- add files
add_files("src/*.cpp")
-- need constexpr
add_options("constexpr") |
I'll focus on improving for example, provide some builtin options in option("find_qt")
on_check(function (option)
-- check qt ...
-- add links, linkdirs .. to option
end) option("xxx_interface")
add_links("xxx")
on_check(function (option)
-- try compile codes
-- try run and test codes (empty implementation?)
end) |
Maybe just translate some I found cmake is licensed under BSD-3 so there's no problem It doesn't have to make a adapter, hand-work is enough @htfy96 |
@titansnow But I don't like cmake's grammar and design, and don't want to be overly reliant on and use them. |
For grammar, I do not like cmake's either But at least we could quickly look through them and come up with some ideas |
Yes, it provides some good features and ideas. I will refer to them when I begin to improve |
But I don't want to parse them for fast implementation, I need design the whole architecture first. Even if it will delay some time. |
Yeah, it might be best solution |
I've started to implement some detection modules. I'll add a new interface target("test")
set_kind("binary")
if has_features("const_expr") then
add_defines("-DCONST_EXPR")
add_files("src/*.cpp")
end
if has_features("sanitize_address", "floating_point") then
...
end And I will improve target("test")
set_kind("binary")
before_build(function (target)
-- import find_library
import("lib.detect.find_library")
-- find zlib and add links
zlib = find_library("zlib")
if zlib then
target:add_links(zlib.links)
target:add_linkdirs(zlib.linkdirs)
end
end Or option("zlib")
on_check(function (option)
-- import find_library
import("lib.detect.find_library")
-- find zlib and add links
zlib = find_library("zlib")
if zlib then
option:add_links(zlib.links)
option:add_linkdirs(zlib.linkdirs)
end
end
target("test")
add_options("zlib") |
detect modules roadmap:
|
winreg roadmap:
|
@htfy96 @titansnow I have implemented these features, please see: new-features-v2.1.5 |
The main reason why I still stick to CMake is its builtin modules which provide compiler detection/package search/etc. It is unnecessary to reinvent the wheels, so I was wondering is it possible to provide (at least kind of)
.cmake
support and wrap these modules intoxmake
utilities?The text was updated successfully, but these errors were encountered: