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

Auto generate module map file for C libs #219

Merged
merged 6 commits into from Apr 6, 2016

Conversation

aciidb0mb3r
Copy link
Member

@aciidb0mb3r aciidb0mb3r commented Mar 22, 2016

This generates modulemap files according to the C proposal https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md

Additionally if there is no include dir then it will emit an empty modulemap file with a warning.

public func generateModuleMap() throws {

//Return if module map is already present
guard !moduleMapPath.isFile else {
Copy link
Contributor

@czechboy0 czechboy0 Mar 22, 2016

Choose a reason for hiding this comment

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

What happens when a new header file is added and the modulemap file is checked in? Won't that not generate a new modulemap and thus not make the new header file available?

Copy link
Member Author

@aciidb0mb3r aciidb0mb3r Mar 22, 2016

Choose a reason for hiding this comment

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

Yeah there are two problems currently...

  • module maps should probably be generated in build dir
  • incremental map generation

Copy link
Contributor

@mxcl mxcl Mar 31, 2016

Choose a reason for hiding this comment

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

Indeed, I did not realize we were not generating them to the build directory. We should be doing that if we are going to generate at all.

Copy link
Member Author

@aciidb0mb3r aciidb0mb3r Mar 31, 2016

Choose a reason for hiding this comment

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

will move the generation to build dir

@aciidb0mb3r
Copy link
Member Author

aciidb0mb3r commented Mar 23, 2016

@mxcl review/CI

@mxcl
Copy link
Contributor

mxcl commented Mar 31, 2016

Maybe it should error if there is no includes and it is a library? Since it is impossible to import it.

I'm mainly thinking of the packaging graph. We don't want broken packages in the wild.

OTOH maybe this is tedious.

@aciidb0mb3r
Copy link
Member Author

aciidb0mb3r commented Mar 31, 2016

Maybe it should error if there is no includes and it is a library? Since it is impossible to import it.

I'm mainly thinking of the packaging graph. We don't want broken packages in the wild.

OTOH maybe this is tedious.

  • Module map is only generated for libraries
  • if includes is not present then it creates an empty module map with a warning
  • if includes is present and is empty it errors out

should I change it to not emit empty module and error out?

@mxcl
Copy link
Contributor

mxcl commented Mar 31, 2016

should I change it to not emit empty module and error out?

I think this would be more consistent considering:

if includes is not present then it creates an empty module map with a warning

@ddunbar
Copy link
Member

ddunbar commented Mar 31, 2016

We definitely should be generating this stuff into a side directory in the build dir.

I would prefer it not be an error to not have includes for a lib, just because that is useful when starting development. In general, I prefer it not to be an error for things that are "well formed" even if they aren't totally usable

@mxcl
Copy link
Contributor

mxcl commented Mar 31, 2016

I would prefer it not be an error to not have includes for a lib, just because that is useful when starting development. In general, I prefer it not to be an error for things that are "well formed" even if they aren't totally usable

Maybe instead of:

if includes is not present then it creates an empty module map with a warning

We do:

if includes is not present then it creates no module-map, but warns that you should create an includes directory because otherwise it is a useless library-module

Which then flows nicely with the existing:

if includes is present and is empty it errors out

@ddunbar
Copy link
Member

ddunbar commented Apr 1, 2016

Sounds good to me!

@aciidb0mb3r
Copy link
Member Author

aciidb0mb3r commented Apr 1, 2016

done, done, done and done 😄

@mxcl @ddunbar re-review


protocol Buildable {
var targetName: String { get }
var isTest: Bool { get }
}

extension CModule {
func workingDirectory(prefix: String) -> String {
Copy link
Member

@ddunbar ddunbar Apr 2, 2016

Choose a reason for hiding this comment

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

Can we get a documentation comment explaining what this function is?

Also, I think "workingDirectory" isn't the best name, something like "buildDirectory" would be closer to the intent.

Copy link
Member Author

@aciidb0mb3r aciidb0mb3r Apr 4, 2016

Choose a reason for hiding this comment

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

fixed

@aciidb0mb3r
Copy link
Member Author

aciidb0mb3r commented Apr 4, 2016

@ddunbar addressed the comments re-review

@ddunbar
Copy link
Member

ddunbar commented Apr 4, 2016

@swift-ci please test

let package = Package(
name: "ModuleMapGenerationCases",
targets: [
Target(name: "Baz", dependencies: ["Foo", "Bar", "Jaz"])]
Copy link
Member

@ddunbar ddunbar Apr 4, 2016

Choose a reason for hiding this comment

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

I would recommend renaming the subdirs here to match what the intent they are trying to test is. Otherwise, when someone comes back to this test they won't necessarily know why each case exists.

Copy link
Member Author

@aciidb0mb3r aciidb0mb3r Apr 4, 2016

Choose a reason for hiding this comment

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

done

@ddunbar
Copy link
Member

ddunbar commented Apr 4, 2016

@swift-ci please test

return ["-Xcc", "-fmodule-map-file=\(module.moduleMapPath)"]
}
let genModuleMap = Path.join(module.buildDirectory(prefix), module.moduleMap)
return ["-Xcc", "-fmodule-map-file=\(genModuleMap)"]
Copy link
Member

@ddunbar ddunbar Apr 4, 2016

Choose a reason for hiding this comment

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

Maybe this is obvious, but I am not seeing how this doesn't fail for non-library C language targets?

Copy link
Member

@ddunbar ddunbar Apr 4, 2016

Choose a reason for hiding this comment

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

I still think it is unfortunate that we are more or less recomputing state here which is independently computed by generateModuleMap. I don't think this is fixable in the current SwiftPM architecture, but it would be good to include a comment which points out that the behavior here is tied to that of the other function (and vice versa), so that if someone updates one they know to look at the other.

Copy link
Member Author

@aciidb0mb3r aciidb0mb3r Apr 4, 2016

Choose a reason for hiding this comment

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

they wont really be in dependencies

Copy link
Member Author

@aciidb0mb3r aciidb0mb3r Apr 4, 2016

Choose a reason for hiding this comment

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

Adding comment, but will push once CI returns


///There are three possible cases for which we will generate modulemaps:
///Flat includes dir with only header files, in that case we generate
/// `umbrella "path/to/includes/"`
Copy link
Member

@ddunbar ddunbar Apr 4, 2016

Choose a reason for hiding this comment

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

I think we should generate umbrella header "foo.h" even for the flat layout, if "foo.h" exists.

@aciidb0mb3r
Copy link
Member Author

aciidb0mb3r commented Apr 5, 2016

@ddunbar updated the generation logic to :

1. Look for include/foo/foo.h, if so, use umbrella header and error if there are any other dirs or headers outside of there
2. Look for include/foo.h, if so, use umbrella header and error if there are any other dirs outside of there
3. All other cases, just use umbrella dir and don't bother to diagnose anything else

@ddunbar
Copy link
Member

ddunbar commented Apr 5, 2016

@swift-ci please test

@ddunbar
Copy link
Member

ddunbar commented Apr 5, 2016

LGTM!

A nice follow on would be to have more explanation in the "invalid layout" cases about exactly what failed, e.g.:
error: unable to generate module map for "include/foo/foo.h" with stray header file "include/bar.h"
or something (could use some more word smithing). Anything to give the user an idea of exactly what it was that kicked them out of the convention path.

@aciidb0mb3r
Copy link
Member Author

aciidb0mb3r commented Apr 5, 2016

Yay! Cool. I'll try to improve the error messages in another PR

these are the updated cases for generating modulemaps:

1. Look for include/foo/foo.h, if so, use umbrella header and error if there are any other dirs or headers outside of there
2. Look for include/foo.h, if so, use umbrella header and error if there are any other dirs outside of there
3. All other cases, just use umbrella dir and don't bother to diagnose anything else
@aciidb0mb3r
Copy link
Member Author

aciidb0mb3r commented Apr 5, 2016

Fixed the linux error, @ddunbar re run CI please

@ddunbar
Copy link
Member

ddunbar commented Apr 5, 2016

@swift-ci please test

@aciidb0mb3r
Copy link
Member Author

aciidb0mb3r commented Apr 5, 2016

osx tests keep failing due to some watch kit thingy

@aciidb0mb3r
Copy link
Member Author

aciidb0mb3r commented Apr 6, 2016

@mxcl @ddunbar can you retrigger CI

@ddunbar
Copy link
Member

ddunbar commented Apr 6, 2016

@swift-ci please test and merge

@ddunbar
Copy link
Member

ddunbar commented Apr 6, 2016

@swift-ci please test

@aciidb0mb3r aciidb0mb3r merged commit e93a62d into apple:master Apr 6, 2016
2 checks passed
@aciidb0mb3r aciidb0mb3r deleted the modulemap_generation branch Apr 6, 2016
@ddunbar
Copy link
Member

ddunbar commented Apr 6, 2016

Thanks!

aciidb0mb3r pushed a commit to aciidb0mb3r/swift-package-manager that referenced this pull request Jan 11, 2019
Implemented a build manifest generator to help stress test llbuild.
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.

None yet

4 participants