Desktop AOT engine builds download

[provokateurin]

From the wiki I can download the JIT compiled versions of the engine for MacOS, Linux and Windows uploaded by the build-bots.

Are there build-bots for the AOT versions of the engine? And if yes where can I download these versions?

[provokateurin]

@kf6gpe You are mentioned in this wiki. Can you help with this? I figured out the flutter infra config needs to be updated in order to get AOT engine uploads. For me it even looks like the AOT engine is already build for linux and mac.

[kf6gpe]

Good question -- I'm actually not sure myself. Let's ask @godofredoc, who's doing a lot of our infrastructure stuff these days. I'm also going to add a few labels to help this get on people's radar better.

[jonahwilliams]

We do not have the capability to build functional AOT configurations for Linux and Windows desktop currently

[jonahwilliams]

Also see https://github.com/flutter/flutter/issues/43454

[csnewman]

Any updates on AOT builds?

Currently for flutter-rs, we use Github actions to build AOT flutter-engine builds. While it has worked for us for the last 4 months or so, having to maintain it is a pain, especially when changes occur with Github Actions. We also have a lag period between when a flutter release occurs, and when our CI runs. We have a patch to include the icudtl data in the binaries to make our lives easier, however once #48160 is resolved, we would be able to move to the official binaries.

[jonahwilliams]

This issue should probably be closed in favor of https://github.com/flutter/flutter/issues/50778 . There will not be any progress made here until we can actually use the AOT artifacts.

[stuartmorgan]

@jonahwilliams We aren't ever planning on using what's being requested here though, which is specifically the stand-alone engine. It's not related to any of the officially maintained embeddings.

Any updates on AOT builds?

We don't have any plans to do this at the moment, which is why there haven't been any updates. Mainly what's needed here is a policy decision about whether or not we want to add this to our infrastructure. If we do, it would just be a recipe change. @cbracken, thoughts?

[stuartmorgan]

I was thinking about this over the weekend given the discussions in the PRs above, and I think what we should actually do is stop uploading the debug desktop engine builds (and wontfix this).

As the the wiki page says:

If you want to build Flutter embedders on one of the platforms not supported out of the box (i.e, iOS & Android), this page is for you.

They are not supported on any platform where we plan to be the publisher of a Flutter runtime distinct from the applications that run on the runtime

We would generally recommend using custom engine builds only when porting Flutter to platforms that are not supported out of the box

At the time they started being uploaded, desktop fit that description, but it no longer does. We're now in the position where the only prebuilts we're posting for the embedder API are for platforms where we recommend (on the same page we link to them) against using that API, which is a confusing message. Given that we have a documented philosophy for how we expect the API to be used, we should update to once again be consistent with that philosophy, and not have the desktop artifacts.

In any other case, someone building on the embedder API needs to build their own engine, so the current flutter-rs approach seems like the right one for a project that wants to support arbitrary versions.

[chinmaygarde]

@stuartmorgan: I disagree. The Embedder API was designed for the creative use of Flutter in environments the Flutter Team could not reach. This is still the case and, within reason, we want to lower the barrier to entry for such endeavors. The ample caveats on the wiki are an effort to warn embedder authors about the magnitude of effort necessary to write a fully featured embedder implementation. Building the engine is busywork and, as we have already seen with more mature embedders, something the embedder author usually ends up taking the responsibility for anyway. When these artifacts started being uploaded, the desktop effort did not exist. But, these artifacts were undoubtedly useful for that effort (and many others during at least the prototyping phases). I see no reason to stop uploading these artifacts now that the desktop effort has matured. The maintainability of these artifacts has remained constant for years.

I do agree that the tone of wiki article is not very cohesive. That's probably because the addendum was added later by a different author. But, the intent was not to dissuade folks from writing their own embedders. Instead it was to be upfront about the effort they would need to take (in a mostly self directed fashion) in order to get a fully realized embedder implementation. I'll reword this wiki to better reflect this message as I did not realize that wording could be construed to mean we didn't want folks using the embedder API before you pointed it out.

About the original ask, SGTM as those artifacts are already being built, tested and have a stable ABI/API.

[stuartmorgan]

The Embedder API was designed for the creative use of Flutter in environments the Flutter Team could not reach. This is still the case and, within reason, we want to lower the barrier to entry for such endeavors.

But that's my point; uploading desktop artifacts is no longer reducing the barrier to entry for environments the Flutter Team isn't reaching, because we are reaching desktop now.

When these artifacts started being uploaded, the desktop effort did not exist.

Well, FDE existed (and, IIRC, is the reason they started being uploaded in the first place). But again, that seems like an argument for why we don't need them any more, not why we should keep them.

I see no reason to stop uploading these artifacts now that the desktop effort has matured.

Is there a reason we upload desktop builds but not mobile builds, if we believe that providing prebuilts of this library is a good idea for platforms that we directly support with an embedding layer?

[chinmaygarde]

But that's my point; uploading desktop artifacts is no longer reducing the barrier to entry for environments the Flutter Team isn't reaching, because we are reaching desktop now.

The desktop effort is still only likely to cover a subset of the potential use-cases for Flutter in a desktop like environment though (or maybe that is just my sincere hope). The fact that this issue was opened in the first place is likely a signal that there are use cases that may be better served by a different take on an embedder. Anecdotally, I have used these artifacts for preparing POCs for embedders that later went on to ship. It is entirely possible that I could be underestimating the desired capabilities of the higher level API in the desktop effort. Either way, these artifacts are the least opinionated / lowest level way of using the engine and I consider there to be some value in that.

... But again, that seems like an argument for why we don't need them any more, not why we should keep them.

The author of this PR seems to have a need for this. The artifact is something whose maintainability has remained constant for years and something we have to build anyway. Removing this seems like change for changes sake.

if we believe that providing prebuilts of this library is a good idea for platforms that we directly support with an embedding layer?

I think we are getting to the root of our disagreement. In my view, the Embedder API is just a library. The library can be used by folks to write an embedder, or, it can itself be wrapped to provide higher level functionality. Either way, the embedding layer and this library are at different positions in the tech stack. One is not a substitute for the other. Maybe the concern is that the presence of these artifacts is causing confusion? In that case, clarifications in the wiki would be the best way to address the same IMO.

[stuartmorgan]

In that case, clarifications in the wiki would be the best way to address the same IMO.

Summarizing from some Discord discussion: My issue with the current situation is purely that we have on one hand a written position that suggests that we should not have these artifacts, and on the other hand a set of artifacts that are uploaded because of historical decisions that are no longer relevant, and that disconnect is not a good situation.

I believe we should a clear policy about what we upload and why, from which answers to requests like this one can be clearly determined. My argument above for removing them was based on the assumption that the philosophy currently described on the wiki was correct, and trying to derive an answer from that, but I'm happy with a solution where we update the wiki with a policy that would clearly lead to an answer of having the current artifacts, or of having all the desktop artifacts, just so long as it's clear.

Removing this seems like change for changes sake.

This bug was requesting change; my goal is that we make change to align our described goals/policy and our practice (in whatever direction), rather than arbitrary change.

@chinmaygarde Do you want to self-assign this to update the wiki with a proposed policy for embedder artifacts?

[JanezStupar]

@stuartmorgan but the fact is that official embedder is not yet ready for use and that the flutter team is preventing us from attempting to use it on our projects by hiding information and even disabling development on desktop platforms.

What would be the right thing to do is to keep supporting 3rd party embedders until one can actually build and deliver software using official embedders.

What you are arguing for here is a bureaucratic solution that will kill goodwill with those of us who are looking to become early adopters of flutter on desktop platforms.

[stuartmorgan]

the fact is that official embedder is not yet ready for use

https://flutter.dev/desktop

the flutter team is preventing us from attempting to use it on our projects by hiding information

I have no idea what this is referring to; if there's information you believe should be in the documentation, please file a new issue.

and even disabling development on desktop platforms

Again, I'm not sure what this is referring to. I can't think of any instances of us disabling any desktop development. Again, please file an issue with details.

What would be the right thing to do is to keep supporting 3rd party embedders

Third-party embeddings are supported. The embedder API is stable, supported, and documented, explicitly for that purpose. Nobody is proposing changing that.

The only question is whether we should be providing pre-built libraries, and if so which platforms and variants.

until one can actually build and deliver software using official embedders

Please file issues with anything blocking you from doing this. But support for third-party embeddings is definitely not conditional on the non-existence of supported embeddings; again, there are no proposals to remove support for third-party embedding support.

What you are arguing for here

You do not appear to have read all of my comments. The only thing I am arguing for at this point is that our stated philosophy for deciding what artifacts we post should match the reality of what we post, which should not be a controversial position. You'll notice that the very last thing I said here indicated that this issue is waiting for an update to the former.

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.