How about doing the same as with gecko? Provide the user with a question (or a list of optional components) that he can install.
On 21 March 2017 at 10:40, Kamil Hornicek <[email protected]> wrote: > Basically this. I'll only add few other points: > > - Mesa sources is 5k files, llvm is 15k, so we have 20k files we'd have to > add to trunk. > - We had Mesa in our tree once and I only managed to update it once or twice > during the nine(?) years I'm with the project, because it's *HUGE* and it > requires a siginificant effort to pull it off. > - If you're still not convinced you can try updating the Mesa code we > currently have in opengl32 and that's just a tiny chunk of the Mesa > codebase. > > Having Mesa in our tree would actually make it much harder to update it, > believe me I've been there. > > Also this is just a temporary solution until we fully support graphics cards > drivers. Any more time spent on this would be wasted. > > Let's not discuss adding Mesa to the tree, let's instead come up with a > solution for providing the user with some "essential/optional" binaries > during or after the setup process. > > K. > > > Dne 21.3.2017 1:48, Zachary Gorden napsal(a): >> >> Mesa is really not a good example of something that should be added to >> the ROS tree due to desired functionality. Its src is almost 5K files by >> itself, when trunk is only a little under 20K files. Then there's its >> rather esoteric build setup. I'm mildly curious as to whether Kamil >> actually built it on Windows or if he needed to pull off a >> cross-compilation on Linux instead. Getting RosBE to be able to build >> Mesa is a nontrivial exercise. To try to incorporate Mesa is to take on >> a large engineering task for what is not necessarily a big payoff. We >> have an existing opengl implementation. Its performance sucks, sure, but >> if you wanted actually performant 3D graphics you would need to go and >> install a proper graphics driver anyway. For out of the box, all it >> needs to do is provide a sufficient degree of compatibility. >> >> SVN also has the equivalent of modules, externals. The project just >> never bothered setting up the repo to make use of them. >> >> On Mon, Mar 20, 2017 at 6:51 PM, Hermès BÉLUSCA-MAÏTO >> <[email protected] <mailto:[email protected]>> wrote: >> >> And another reason to make our SVN source tree structure modularized. >> >> -----Message d'origine----- >> De : Ros-dev [mailto:[email protected] >> <mailto:[email protected]>] De la part de Colin Finck >> Envoyé : lundi 20 mars 2017 23:05 >> À : [email protected] <mailto:[email protected]> >> >> Objet : Re: [ros-dev] [ros-diffs] [khornicek] 74209: [RAPPS] - Add a >> custom build of the Mesa 3D Graphics Library. This build contains >> mesa, gallium and llvmpipe. It provides an enormous performance >> boost over the software implemen... >> >> Am 20.03.2017 um 09:44 schrieb Kamil Hornicek: >> > few other people asked me, but Jerome did it right. Mesa code base >> is >> > rather big and llvm is not small either. Integrating it in our >> > building process and keeping it in sync would require huge amount >> of >> > effort. It would also increase both the ISOs and the build time. >> >> I'm seeing more and more people afraid of adding anything "big" to >> our tree. But this is just natural for a project that aims to become >> a fully fledged operating system! >> >> The worst thing would be an OS that can be quickly compiled from >> scratch and then needs lots of binary blobs to be useful. Even >> worse, those binary blobs could hardly be verified and patched. >> Don't forget we already had that with our schannel.dll >> implementation that depended on an external GnuTLS binary. >> Fortunately, this is fixed by now and ReactOS supports TLS out of >> the box. >> I would like to see the same for a Mesa/Gallium/llvmpipe stack. >> Having one somewhere hidden in RAPPS, but not in an out of the box >> ReactOS installation from the ReactOS giveaway CDs would be very >> disappointing... >> >> I also understand the group though who wants the default ReactOS >> build to be lightweight. So maybe Mesa/Gallium/llvmpipe could become >> part of another module which is added through our "modules" >> subdirectory. >> Our current SVN setup with just one ReactOS repository does not >> really encourage adding new modules. Another reason for a move to >> Git where everybody could easily put his big module into an own >> repository :) >> >> >> Cheers, >> >> Colin >> >> _______________________________________________ >> Ros-dev mailing list >> [email protected] <mailto:[email protected]> >> http://www.reactos.org/mailman/listinfo/ros-dev >> <http://www.reactos.org/mailman/listinfo/ros-dev> >> >> >> _______________________________________________ >> Ros-dev mailing list >> [email protected] <mailto:[email protected]> >> http://www.reactos.org/mailman/listinfo/ros-dev >> <http://www.reactos.org/mailman/listinfo/ros-dev> >> >> >> >> >> _______________________________________________ >> Ros-dev mailing list >> [email protected] >> http://www.reactos.org/mailman/listinfo/ros-dev >> > > _______________________________________________ > Ros-dev mailing list > [email protected] > http://www.reactos.org/mailman/listinfo/ros-dev _______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
