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

[WIP] move lib/include dir search into @rules in native_toolchain.py #6271

Conversation

cosmicexplorer
Copy link
Contributor

@cosmicexplorer cosmicexplorer commented Jul 29, 2018

WIP because I'm waiting on #6374 to use the datatype default value helpers.

Problem

Searching for lib and include directories to provide to our compilers and linkers is still pretty brittle. Part of this is that while we provide include dirs through e.g. the CPATH environment variable, clang and gcc will still prefer "system" include dirs they find themselves over ours, and this leads to e.g. breakages across untested linux platforms.

Solution

  • Add -nostdinc, -nobuiltininc (this is osx-only), and -nostdinc++ where possible to our compiler command lines in native_toolchain.py to stop them from searching for include directories by themselves.
  • Remove LibcDev and ParseSearchDirs to move al(most al)l toolchain configuration into native_toolchain.py, where we search for lib dirs as before (by parsing the output of a compiler executable invocation), and also introduce include path searching in the same way, but invoking the compiler with a different command.
  • Change library_dirs from Executable to be instead named runtime_library_dirs.

Result

The logic from LibcDev and ParseSearchDirs is now spread into several @rules in native_toolchain.py, and that functionality is now much easier to access. We now separately search for include directories, which allows us to turn on -nostdinc/etc and have deeper control over what resources we pull in for compilation.

@cosmicexplorer cosmicexplorer changed the title [WIP] move lib/include dir search into @rules in native_toolchain.py and remove ParseSearchDirs and LibcDev [WIP] move lib/include dir search into @rules in native_toolchain.py Jul 29, 2018
cosmicexplorer added a commit to cosmicexplorer/pants that referenced this pull request Jul 30, 2018
cosmicexplorer added a commit to cosmicexplorer/pants that referenced this pull request Jul 30, 2018
}

def as_execute_process_request(self, more_args=None):
argv = [self.exe_filename] + self.extra_args + (more_args or [])
Copy link
Contributor

Choose a reason for hiding this comment

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

more_args can be a tuple here to eliminate the or

Copy link
Contributor

Choose a reason for hiding this comment

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

Only sort-of. If you want to be defensive, this is appropriate. The caller can explicitly pass None.

@@ -90,7 +90,7 @@ def linker(self, platform):
path_entries=self.path_entries,
exe_filename=platform.resolve_platform_specific(
self._PLATFORM_SPECIFIC_LINKER_NAME),
library_dirs=[],
runtime_library_dirs=[],
linking_library_dirs=[],
Copy link
Contributor

Choose a reason for hiding this comment

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

Im slightly confused on the difference here between runtime_library_dirs and linking_library_dirs. Is the latter for static libs?

Copy link
Contributor Author

@cosmicexplorer cosmicexplorer Sep 1, 2018

Choose a reason for hiding this comment

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

Directories containing shared libraries that must be on the runtime library search path. (this is LD_LIBRARY_PATH or DYLD_LIBRARY_PATH) vs Directories to search for libraries needed at link time. (this is LIBRARY_PATH, it's for both static and shared libs).

def parse_known_lib_dirs(compiler_search_request):
# FIXME: convert this to using `copy()` when #6269 is merged.
cmplr = compiler_search_request.compiler
print_search_dirs_exe = type(cmplr)(path_entries=cmplr.path_entries,
Copy link
Contributor

@CMLivingston CMLivingston Jul 30, 2018

Choose a reason for hiding this comment

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

These should be tuples to conform to other compiler instantiations in this changeset. I may be missing something, but its good to have consistency. Also, not sure how I feel about this construction using type. Might be cleaner to have this as a class method on the compiler class, however I don't have any explicit reason to change this beyond Python conventions/readability.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 to classmethod over constructor here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I mentioned that this should be using a .copy() method with an explicit comment -- that has now been implemented and removes all of this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If by "tuples" you mean positional arguments, that's much more brittle to future changes in the fields of the datatype than explicitly specifying keyword arguments in a .copy() call.

# c_compiler=c_compiler.copy(include_dirs=compiler_search_output.include_dirs.dirs),
# c_linker=c_linker.copy(linking_library_dirs=compiler_search_output.lib_dirs.dirs)))
resolved_c_toolchain = CToolchain(
c_compiler=CCompiler(path_entries=c_compiler.path_entries,
Copy link
Contributor

Choose a reason for hiding this comment

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

tuples here as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What is meant by "tuples" here?

Copy link
Contributor

@CMLivingston CMLivingston left a comment

Choose a reason for hiding this comment

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

Thanks for doing this! This is a huge improvement to the native toolchain and makes the compile environment way easier to understand. I left a few comments/questions but no blockers. Feel free to take or leave the suggestions.

Also, I would like to see one more approval by a developer who is more familiar with rules and snapshots. I am still wrapping my head around these concepts, however details of rules aside, these changes look good to me.

}

def as_execute_process_request(self, more_args=None):
argv = [self.exe_filename] + self.extra_args + (more_args or [])
Copy link
Contributor

Choose a reason for hiding this comment

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

Only sort-of. If you want to be defensive, this is appropriate. The caller can explicitly pass None.

]), LinkerMixin):

@property
def with_tupled_collections(self):
Copy link
Contributor

Choose a reason for hiding this comment

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

The 3 with_tupled_collections are unused - kill. Additionally, with_* reads like a verb and not like a noun, so either @property is not appropriate or the naming is suboptimal.

def parse_known_lib_dirs(compiler_search_request):
# FIXME: convert this to using `copy()` when #6269 is merged.
cmplr = compiler_search_request.compiler
print_search_dirs_exe = type(cmplr)(path_entries=cmplr.path_entries,
Copy link
Contributor

Choose a reason for hiding this comment

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

+1 to classmethod over constructor here.

@cosmicexplorer cosmicexplorer force-pushed the refactor-lib-include-search-native branch from fbdac6e to e582161 Compare September 1, 2018 10:03
@Eric-Arellano
Copy link
Contributor

Closing due to being stale, such as no longer using datatype.

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.

4 participants