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

[singlejar] Port test_util to Windows #6248

Closed
wants to merge 5 commits into from

Conversation

rongjiecomputer
Copy link
Contributor

@rongjiecomputer rongjiecomputer commented Sep 26, 2018

  • Port various functions in test_util to Windows.
  • Replace @local_jdk//:jdk-default with @bazel_tools//tools/jdk:current_java_runtime.

See #2241

@rongjiecomputer
Copy link
Contributor Author

PTAL @meteorcloudy

@meteorcloudy
Copy link
Member

I've imported this change, but the C++ runfiles library doesn't work well internally. I need some time to debug and fix the issue. Sorry for the delay.

@laszlocsomor
Copy link
Contributor

I'll take a look at why the runfiles library is failing in the Google-internal code base.

src/tools/singlejar/BUILD Outdated Show resolved Hide resolved
src/tools/singlejar/BUILD Outdated Show resolved Hide resolved
int main(int argc, char** argv) {
std::string error;
std::unique_ptr<singlejar_test_util::Runfiles> runfiles(
singlejar_test_util::Runfiles::Create(argv[0], &error));
Copy link
Contributor

Choose a reason for hiding this comment

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

Unfortunately I can't fix the error without patching the runfiles library, which I'm about to do. Could you please hold this PR until that one is merged?

My patch will, among other things, add a static Runfiles* Runfiles::CreateForTest(void) method, which won't require argv0. Therefore there'll be no need for a custom main method.

Once my patch is in, could you please init the runfiles either on-demand (in tests that need it) or in the setUp method, using the upcoming CreateForTest factory method?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Could you please hold this PR until that one is merged?

Sure thing. Ping me when that PR is merged. #6251 probably will need some changes too, so don't review that one yet.

@@ -114,4 +135,19 @@ string CreateTextFile(const string& relpath, const char *contents) {
return string("");
}

Runfiles* runfiles = nullptr;
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a way to not use a global variable? (Maybe by initializing runfiles in the setUp method?)

Copy link
Contributor Author

@rongjiecomputer rongjiecomputer Sep 27, 2018

Choose a reason for hiding this comment

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

Initializing runfiles in the setUp is fine. I used global variable when I started porting tests out of convenience.

@laszlocsomor
Copy link
Contributor

@rongjiecomputer : Thank you so much for waiting! #6267 is now merged.

@rongjiecomputer
Copy link
Contributor Author

@laszlocsomor This PR is ready now.

@laszlocsomor
Copy link
Contributor

Thanks @rongjiecomputer ! I don't see the code using the runfiles library anywhere. Did you mean to use it, or just adding the dependency?

@rongjiecomputer
Copy link
Contributor Author

That will be in #6251, which I have not yet updated.

@@ -87,7 +108,7 @@ string GetEntryContents(const string &zip_path, const string &entry_name) {
string command;
blaze_util::StringPrintf(&command, "unzip -p %s %s", zip_path.c_str(),
entry_name.c_str());
FILE *fp = popen(command.c_str(), "r");
FILE *fp = popen(command.c_str(), "rb");
Copy link
Contributor

Choose a reason for hiding this comment

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

Unfortunately this change breaks the internal version of output_jar_simple_test.
Is this change necessary?

Copy link
Contributor

Choose a reason for hiding this comment

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

http://man7.org/linux/man-pages/man3/popen.3.html doesn't document b; it seems to be Microsoft-specific.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The "b" is necessary because otherwise the Microsoft implementation will strip \r\n to \n and make many tests fail. I will add a _WIN32 guard for this.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks!
With your permission, I'd like to also add this comment:

  // "b" is Microsoft-specific. It's necessary, because without it the popen
  // implementation will strip "\r\n" to "\n" and make many tests fail.

(If you agree to it, just let me know, no need to upload a new commit.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You have my permission.

@laszlocsomor
Copy link
Contributor

I haven't forgotten about this! Trying to merge now, tests are still running.

@@ -232,12 +232,13 @@ cc_test(
":test1",
":test2",
"@local_jdk//:jar",
"@local_jdk//:jdk-default",
"@local_jdk//:jdk",
Copy link
Contributor

Choose a reason for hiding this comment

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

Ideally, this would be fixed not to use @local_jdk. Also, did this test not actually run before? There's no :jdk-default target, I think.

Copy link
Contributor Author

@rongjiecomputer rongjiecomputer Oct 11, 2018

Choose a reason for hiding this comment

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

Ideally, this would be fixed not to use @local_jdk

So what is the alternative?

I also have been wondering whether some of the singlejar tests were even tested before, and whether the //src/tools/singlejar/BUILD in Bazel is different from the Google internal one (because some test files are never included in the BUILD file and see this comment: #6336 (comment)).

Copy link
Contributor

Choose a reason for hiding this comment

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

I believe //external:jdk and //external:jar would be more desirable. Alas, I'm not at all familiar with these JDK rules. I'm consulting with @lberki for advice on the internal review.

Copy link
Contributor

Choose a reason for hiding this comment

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

Me! If all the test needs is to run jar, do this instead:

cc_test(
  name="test",
  data=["@bazel_tols//tools/jdk:current_java_runtime"],
  toolchains=["@bazel_tools//tools/jdk:current_java_runtime"],
  copts=["-DJAR=$(JAVA)/bin/jar"],
)

This way, you get a path to whatever target JDK is used (and not to the result of autodetection), which is the principled thing to do.

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 think we need to add .exe at for the -D flag. Windows also requires different kind of " escaping to pass string constant in -D as const char[]. I will handle that in the second PR, just do whatever that works for Unix first.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds like a plan. You can use select({"@bazel_tools//platforms:windows": ... }) or something like that to handle that case.

Copy link
Contributor

Choose a reason for hiding this comment

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

@rongjiecomputer : shall I apply @lberki 's suggestion (the cc_test rule) to the code and submit internally like so?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure.

@bazel-io bazel-io closed this in 68611b3 Oct 15, 2018
@rongjiecomputer rongjiecomputer deleted the test_util branch October 15, 2018 14:44
laszlocsomor added a commit to laszlocsomor/bazel that referenced this pull request Oct 16, 2018
I introduced these problems while editing the
Google-internal copy of bazelbuild#6248
that was later pushed as bazelbuild@68611b3.

See bazelbuild#2241

Change-Id: Icd981a0fcdcd451a00cbb2babd107f7abb4d5170
bazel-io pushed a commit that referenced this pull request Oct 16, 2018
I introduced these problems while editing the
Google-internal copy of #6248
that was later pushed as 68611b3.

See #2241

Change-Id: Icd981a0fcdcd451a00cbb2babd107f7abb4d5170

Closes #6404.

Change-Id: I33cc9c5890ec5236e7964846c158628c947c715d
PiperOrigin-RevId: 217304415
@philwo philwo added the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Jun 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Windows Windows-specific issues and feature requests cla: yes team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants