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 <hermes.belusca(a)sfr.fr
wrote:
And another reason to make our SVN source tree
structure modularized.
-----Message d'origine-----
De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Colin
Finck
Envoyé : lundi 20 mars 2017 23:05
À : ros-dev(a)reactos.org
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
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev