DRC
2016-12-03 22:16:12 UTC
For those who haven't been following the discussion at
https://github.com/libjpeg-turbo/libjpeg-turbo/issues/56
the dev branch now contains a 100% CMake-based build system. The
decision to eliminate autotools in libjpeg-turbo 1.6 was not one I took
lightly, but CMake's built-in support for assembly and Java code, as
well as other features that are generally more friendly to the needs of
our build and packaging system, solved a lot of problems for us and
eliminated a lot of hacks. In addition, this eliminates the need to
maintain two separate build, packaging, and testing systems going
forward, which will reduce costs for new feature implementations. I
spent something like 60 unpaid hours implementing this, but it will
probably save me much more time than that in the long run.
This will not land in libjpeg-turbo 1.6 beta for at least several
months, which should hopefully give downstream integrators enough time
to test it and make the necessary modifications to their distribution
builds. Please take a moment to test the new build system on your
favorite platform and let me know what breaks. The most common
cross-compilation builds (including iOS, Android, and MinGW) are
documented in BUILDING.md.
If your project or organization will benefit from this work, then please
consider making a donation using the "Donate" button at
http://www.libjpeg-turbo.org/. I have spent hundreds of unpaid hours in
the past couple of months implementing this new build system and the
continuous integration system. Since I don't draw a salary for my work
on open source code, donations and funded development opportunities are
the only way I can get paid for my work, and those sources of funding
are the only thing keeping libjpeg-turbo afloat as a project.
DRC
https://github.com/libjpeg-turbo/libjpeg-turbo/issues/56
the dev branch now contains a 100% CMake-based build system. The
decision to eliminate autotools in libjpeg-turbo 1.6 was not one I took
lightly, but CMake's built-in support for assembly and Java code, as
well as other features that are generally more friendly to the needs of
our build and packaging system, solved a lot of problems for us and
eliminated a lot of hacks. In addition, this eliminates the need to
maintain two separate build, packaging, and testing systems going
forward, which will reduce costs for new feature implementations. I
spent something like 60 unpaid hours implementing this, but it will
probably save me much more time than that in the long run.
This will not land in libjpeg-turbo 1.6 beta for at least several
months, which should hopefully give downstream integrators enough time
to test it and make the necessary modifications to their distribution
builds. Please take a moment to test the new build system on your
favorite platform and let me know what breaks. The most common
cross-compilation builds (including iOS, Android, and MinGW) are
documented in BUILDING.md.
If your project or organization will benefit from this work, then please
consider making a donation using the "Donate" button at
http://www.libjpeg-turbo.org/. I have spent hundreds of unpaid hours in
the past couple of months implementing this new build system and the
continuous integration system. Since I don't draw a salary for my work
on open source code, donations and funded development opportunities are
the only way I can get paid for my work, and those sources of funding
are the only thing keeping libjpeg-turbo afloat as a project.
DRC