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

Hack for conda includes #60

Open
Shaikh-Ubaid opened this issue Jan 9, 2024 · 1 comment
Open

Hack for conda includes #60

Shaikh-Ubaid opened this issue Jan 9, 2024 · 1 comment

Comments

@Shaikh-Ubaid
Copy link
Collaborator

One needs to add their conda include paths below which is a hack.

lc/src/lc/clang_ast_to_asr.h

Lines 1855 to 1870 in 9c855f9

std::vector<std::string> include_paths = {
"include/c++/v1",
"include/stddef.h",
"include/__stddef_max_align_t.h",
"usr/include",
"mambaforge/envs",
"lib/gcc",
"lib/clang",
"micromamba-root/envs",
"micromamba/envs"
};
for( std::string& path: include_paths ) {
if( file_path.find(path) != std::string::npos ) {
return false;
}
}

@certik
Copy link
Contributor

certik commented Jan 11, 2024

We need to fix this in a robust way. Let's see what we need:

  • We need to recognize the C++ standard library and not parse its Clang AST nodes at all, instead recognize what is included (say std::out) and handle it directly
  • We need to recognize user include files and treat them in a special way: parse those separately into an ASR module, and then just include such a module
  • We need to recognize third-party libraries like xtensor, not parse it and treat it directly

How to do that? Here are some ideas:

  • We can require user include names to not clash with C++ standard library nor with any third-party library that we support directly. So iostream will always mean C++ standard library and never a user include. Then we can simply match for the name of the include at the end of the path and be done with it. This will be conda independent and user installation independent. But it has a downside that user include file must not clash, which might be ok for the main include files, but I suspect even a lot of the standard library (and xtensor) recursive includes might have some more "common" names that might clash.
  • We can require a compiler flag (similar to -I) to specify the C++ standard library path, and another or the same flag to also specify xtensor location. And/or a special flag to specify user include locations, for example we could require strict -I flags for all user includes, and if the Clang AST header file is specified explcitly using -I, then it is user header file, otherwise it is "built-in". The problem is what to do if we use a conda environment that has both xtensor and user include files with the same prefix.
  • We can specify conda include dir explicitly, or support something like --include-conda.

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

No branches or pull requests

2 participants