|
sb hermit posted:what is that bespoke clang doing to those machine language binaries???
|
# ? Aug 10, 2023 09:22 |
|
|
# ? May 23, 2024 15:45 |
|
After much fighting, cursing, and head scratching, I am now able to build and run flutter apps using Buildroot!
|
# ? Aug 15, 2023 23:57 |
|
Noice. Have you tried it out to make a fart-app yet? Pretty interested in how well/bad the embedded and web guis work
Poopernickel fucked around with this message at 03:03 on Aug 16, 2023 |
# ? Aug 16, 2023 03:00 |
|
Poopernickel posted:Noice. Have you tried it out to make a fart-app yet? Pretty interested in how well/bad the embedded and web guis work I ported the flutter-gallery app, just haven’t submitted the package yet. Performance is pretty good with a x86 KVM. I don’t have a board to test with yet so QEMU it is.
|
# ? Aug 16, 2023 03:37 |
|
FlapYoJacks posted:I ported the flutter-gallery app; I just haven’t submitted the package yet. Performance is pretty good with an x86 KVM. I don’t have a board to test with yet, so QEMU it is. After 7 versions of the Flutter patch series, I am happy with the results, and everything works properly. Now give Buildroot proper Vulkan support.
|
# ? Aug 30, 2023 17:32 |
|
Nice. Is this gonna make it into the next Buildroot release?
|
# ? Aug 31, 2023 00:39 |
|
Poopernickel posted:Nice. Is this gonna make it into the next Buildroot release? Nah, they are marked as next. The next BR release comes out in the next few days.
|
# ? Aug 31, 2023 00:55 |
|
Does anyone want to take a crack at creating a build cache for Buildroot?
|
# ? Aug 31, 2023 21:22 |
|
FlapYoJacks posted:Does anyone want to take a crack at creating a build cache for Buildroot? Buildroot: don't use Yocto, it's too complicated also Buildroot: oh, wait actually those features might have a point
|
# ? Aug 31, 2023 21:49 |
|
Poopernickel posted:Buildroot: don't use Yocto, it's too complicated Eh, that's been on the list of things to do for quite some time. Buildroot and its maintainers don't say "Don't use Yocto, it's too complicated." They say "Don't use Yocto, setup is a giant pain, and the reliance on community layers is a crapshoot."
|
# ? Aug 31, 2023 21:56 |
|
The actual implementation might not be too bad though, tbh It would probably look something like: 1. Require build isolation 2. Hash all of every package's Make variables (determined by prefix) 3. Build-step also has to learn how to depend on any source files that are local. 4. After package build, install to a temporary DESTDIR 5. Tar up the result, name it by hash, and put it in some cache folder 6. Delete the DESTDIR 7. When populating the sysroot for a new package build, always do it from the cache 8. Set dependency relationships appropriately
|
# ? Aug 31, 2023 21:56 |
|
3 might actually be a doozy if there's no mechanism for it today
|
# ? Aug 31, 2023 21:58 |
|
Poopernickel posted:The actual implementation might not be too bad though, tbh Creating the cache is easy. Yann (one of the maintainers) has already done that. Applying the cache is the difficult part. - To extract a package, you must first extract all its dependencies. Say you have 3 packages, A, B, and C. A depends on C, and B depends on C. Then, when you uncache A, you first need to uncache C. Then, when you uncache B, you first need to uncache C. But C is already uncached because you uncached A. And then consider PPD. You need to uncache, but first, you need to pre-populate as the pre-configure rsyncs, which in turn requires that you are properly uncached dependencies.. Another question to consider: What to do when the build was done in /some/path, then cached, and then extracted for a new build on /some/other/path. So, proper uncaching either requires that we duplicate the logic in the cache script (ugly) or that we integrate uncaching in the package infra (hard.)
|
# ? Aug 31, 2023 22:02 |
|
I'd expect Make's dependency solver to handle that OK though, right? For isolated packages, I'd expect Make logic that looks like:code:
|
# ? Aug 31, 2023 23:20 |
|
Poopernickel posted:I'd expect Make's dependency solver to handle that OK though, right? For isolated packages, I'd expect Make logic that looks like: I would have to look at the make infrastructure again. It's possible, just difficult.
|
# ? Aug 31, 2023 23:29 |
|
FlapYoJacks posted:or that we integrate uncaching in the package infra (hard.) that's the right way to do it imo. Probably some additions to pkg-generic.mk - some pattern rules and some additions to inner-generic-package. After all - what's more fun than digging through an inscrutable web of Make macros?
|
# ? Aug 31, 2023 23:30 |
|
Poopernickel posted:that's the right way to do it imo. Probably some additions to pkg-generic.mk - some pattern rules and some additions to inner-generic-package. If you do it I could get you a plane ticket to FOSDEM. Not joking.
|
# ? Sep 1, 2023 00:01 |
|
FlapYoJacks posted:If you do it I could get you a plane ticket to FOSDEM. Not joking. don't threaten me with a good time Poopernickel fucked around with this message at 00:32 on Sep 1, 2023 |
# ? Sep 1, 2023 00:27 |
|
submitted Vulcan packages. Now you too can have Vulcan support in Buildroot! Surprisingly easy with no real complications.
|
# ? Sep 1, 2023 17:35 |
|
FlapYoJacks posted:If you do it I could get you a plane ticket to FOSDEM. Not joking. how do you think the BR folks would feel about an implementation that used Make's `load` functionality to compile and run a C extension? A correct cache implementation requires me to hash the metadata of each package defined in the build. It would be pretty slow if I had to shell out to sha256sum all the time, and I don't think I could do it in pure Makelang.
|
# ? Sep 1, 2023 22:47 |
|
Poopernickel posted:how do you think the BR folks would feel about an implementation that used Make's `load` functionality to compile and run a C extension? Ask them on irc on the OFTC server #buildroot. Warning: They are French Edit: They of course speak perfect English. The humor, +9 hour time difference, and more direct approach at debate is what the warning covers. FlapYoJacks fucked around with this message at 22:56 on Sep 1, 2023 |
# ? Sep 1, 2023 22:49 |
|
FlapYoJacks posted:Ask them on irc on the OFTC server #buildroot. Warning: They are French eh I don't want to get everybody's hopes up yet. Just want to feel out how it'd be received.
|
# ? Sep 1, 2023 23:28 |
|
Poopernickel posted:eh I don't want to get everybody's hopes up yet. Just want to feel out how it'd be received. I would also say that sha256 is a *bit* overkill for file verification. MD5 would be fine.
|
# ? Sep 1, 2023 23:33 |
|
Dealing with QT4
|
# ? Sep 13, 2023 01:16 |
|
FlapYoJacks posted:Dealing with QT4 show some spirit https://www.youtube.com/watch?v=NbTEVbQLC8s
|
# ? Sep 13, 2023 01:28 |
|
akadajet posted:show some spirit I love that video every time I see it. I figured out the issue with QT4 and parallel package building. QT4 hard codes paths to the compiler tools in all the qmake.conf files it installs. Then, another package will come around and rsync the qt4 host directory and will try to use a gcc/g++ in the wrong directory, which causes linking issues. A sed command and a bunch of cursing later, and all is good. Now I can do the QT4 dance! FlapYoJacks fucked around with this message at 01:31 on Sep 14, 2023 |
# ? Sep 14, 2023 01:27 |
|
Qt4 is nice imo this post sent from 2007
|
# ? Sep 14, 2023 01:54 |
|
hobbesmaster posted:Qt4 is nice imo I’m sure these guys would be on QT5 if they weren’t cheap.
|
# ? Sep 14, 2023 02:08 |
|
Qt 6 is the “not cheap” option
|
# ? Sep 14, 2023 02:11 |
|
hobbesmaster posted:Qt 6 is the “not cheap” option Ignoring licensing is the cheap option. Edit: The time it took to figure this out is well worth the effort. Total build times went from 7 hours to 90 minutes for 7 boards and an emulator. Things changed: - Committed the dl/ directory - Shared ccache between boards with the same processors - Parallel package building.
|
# ? Sep 14, 2023 02:18 |
|
https://gitlab.com/buildroot.org/buildroot/-/tree/master/package/flutter-engine?ref_type=heads
|
# ? Oct 1, 2023 20:11 |
|
The RPI5 is up for pre-orders. Looks like a 4x increase in GPU performance on average.
|
# ? Oct 4, 2023 17:14 |
|
Hey is there an FPGA programming thread and if not should we make one??
|
# ? Oct 4, 2023 23:59 |
|
if you want to talk about MPSoCs and such this would be close enough I suppose?
|
# ? Oct 5, 2023 00:18 |
|
hobbesmaster posted:if you want to talk about MPSoCs and such this would be close enough I suppose? Sure, I mean... I'm a total n00b and just got a Basys 3 introductory board so
|
# ? Oct 5, 2023 00:25 |
|
I have done an FPGA now and then! The basys3 looks sweet, I've never played with it. I shipped a few Artix designs, back before I made the jump from hardware engineer to software engineer. Ask away if you want hot takes that haven't been updated in about 6 years
|
# ? Oct 5, 2023 05:44 |
|
fun-fact for the cool kids: Xilinx supports a yocto linux for its Microblaze soft CPUs shockingly, it's actually not the worst experience if you just want to do some command-and-control type poo poo for your custom FPGA peripherals
|
# ? Oct 5, 2023 05:48 |
|
What's your HOTTEST 6 year old FPGA take??
|
# ? Oct 5, 2023 05:49 |
|
TCL is a good programming language
|
# ? Oct 5, 2023 07:29 |
|
|
# ? May 23, 2024 15:45 |
|
Poopernickel posted:TCL is a good programming language This infers there are good programming languages. shameful.
|
# ? Oct 5, 2023 11:55 |