Skip to content

Conversation

@jonpryor
Copy link
Contributor

Commit cbc6547 attempted to improve brew 1.2 support by skipping
use of sudo when brew 1.2 is detected.

The problem is that this impacts all install command use, not just
brew install command invocations. Consequently, when e.g. attempting
to install a new MonoFramework, things fail because sudo isn't
specified:

$ make MSBUILD_ARGS="/p:AutoProvision=True /p:AutoProvisionUsesSudo=True"
...
Executing: installer -pkg ".../android-archives/MonoFramework-MDK-5.2.0.114.macos10.xamarin.universal.pkg" -target /

which promptly fails because that requires sudo to work.

Fix the <PrepareInstall/> task to only skip sudo use for brew
commands; non-brew commands should continue to get sudo.

Commit cbc6547 attempted to improve brew 1.2 support by *skipping*
use of `sudo` when brew 1.2 is detected.

The problem is that this impacts *all* install command use, not just
`brew install` command invocations. Consequently, when e.g. attempting
to install a new MonoFramework, things *fail* because `sudo` *isn't*
specified:

	$ make MSBUILD_ARGS="/p:AutoProvision=True /p:AutoProvisionUsesSudo=True"
	...
	Executing: installer -pkg ".../android-archives/MonoFramework-MDK-5.2.0.114.macos10.xamarin.universal.pkg" -target /

which promptly fails because that requires `sudo` to work.

Fix the `<PrepareInstall/>` task to only skip `sudo` use for *brew*
commands; non-`brew` commands should continue to get `sudo`.
@radekdoulik radekdoulik merged commit 3bf804b into dotnet:master May 17, 2017
jonpryor pushed a commit that referenced this pull request Mar 16, 2020
Changes: dotnet/java-interop@27cfd45...bd7c60a

  * dotnet/java-interop@bd7c60a: [generator] Support //interface/@no-alternatives (#601)
  * dotnet/java-interop@105d544: [generator] Remove interface alternatives w/ interface-constants (#600)
  * dotnet/java-interop@b255981: [build] Remove extraneous `nuget restore`s (#599)
  * dotnet/java-interop@2a59c40: [CI] Specify our PR build trigger in YAML. (#598)
  * dotnet/java-interop@0a3354b: [Java.Interop.Tools.Cecil] use File.Exists instead of DirectoryGetFile (#596)

Reduces the `<LinkAssembliesNoShrink/>` task time from about 711ms to
426ms for a small test Xamarin.Forms app on an initial clean build.

Updates `generator --lang-features=interface-constants` output so that
we stop emitting the `*Consts` classes in API-R.

API Breakages:

  * `tests/api-compatibility/acceptable-breakages-v10.0.99.txt`:
    These are because we are no longer generating the `*Consts` types
    when for Default Interface Methods are enabled.

  * `tests/api-compatibility/acceptable-breakages-v10.0.txt`:
    These are because there was a bug where we were not generating
    `[Obsolete]` on fields that were turned into properties.  Now the
    attribute is generated in API-28 (the "contract"), but they are no
    longer marked as deprecated by Google in API-29
    (the "implementation"), so they appear as removing the attribute.

  * `tests/api-compatibility/acceptable-breakages-v8.0.txt`:
    As with v10.0, a "prop-ified" field was missing `[Obsolete]`, and
    Google later un-deprecated the field.
jonpryor pushed a commit that referenced this pull request Mar 16, 2020
Changes: dotnet/java-interop@35f30bf...a84d19e

  * dotnet/java-interop@a84d19e: [generator] Support //interface/@no-alternatives (#601)
  * dotnet/java-interop@f34ed03: [generator] Remove interface alternatives w/ interface-constants (#600)
  * dotnet/java-interop@c5b8aca: [CI] Specify our PR build trigger in YAML. (#598)
  * dotnet/java-interop@d589f1c: [Java.Interop.Tools.Cecil] use File.Exists instead of DirectoryGetFile (#596)

Reduces the `<LinkAssembliesNoShrink/>` task time from about 711ms to
426ms for a small test Xamarin.Forms app on an initial clean build.

Updates `generator --lang-features=interface-constants` output so that
we stop emitting the `*Consts` classes in API-R.

API Breakages:

  * `tests/api-compatibility/acceptable-breakages-v10.0.99.txt`:
    These are because we are no longer generating the `*Consts` types
    when for Default Interface Methods are enabled.

  * `tests/api-compatibility/acceptable-breakages-v10.0.txt`:
    These are because there was a bug where we were not generating
    `[Obsolete]` on fields that were turned into properties.  Now the
    attribute is generated in API-28 (the "contract"), but they are no
    longer marked as deprecated by Google in API-29
    (the "implementation"), so they appear as removing the attribute.

  * `tests/api-compatibility/acceptable-breakages-v8.0.txt`:
    As with v10.0, a "prop-ified" field was missing `[Obsolete]`, and
    Google later un-deprecated the field.
@github-actions github-actions bot locked and limited conversation to collaborators Feb 5, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants