Only configure.ac patch this time .. diff --git a/cinelerra-5.1/configure.ac b/cinelerra-5.1/configure.ac index f10af67..7375fa9 100644 --- a/cinelerra-5.1/configure.ac +++ b/cinelerra-5.1/configure.ac @@ -8,7 +8,7 @@ AC_LANG_CPLUSPLUS AC_LANG_C AC_PROG_CXX -CFG_CFLAGS+=" -fno-omit-frame-pointer -fno-math-errno -fno-signed-zeros" +CFG_CFLAGS+=" -std=c++11 -fno-omit-frame-pointer -fno-math-errno -fno-signed-zeros" CFG_CFLAGS+=" -pthread -Wall" # misguided pedantic warnings # this is extra work, not a gain... @@ -239,14 +239,14 @@ PKG_3RD([giflib],[yes], libutil.a ], [ . ]) -PKG_3RD([ilmbase],[auto], - [ilmbase-2.2.1], - [ Iex/.libs/libIex.a \ - IexMath/.libs/libIexMath.a \ - Half/.libs/libHalf.a \ - Imath/.libs/libImath.a \ - IlmThread/.libs/libIlmThread.a ], - [ Iex Half Imath config IlmThread ]) +#PKG_3RD([ilmbase],[auto], +# [ilmbase-2.2.1], +# [ Iex/.libs/libIex.a \ +# IexMath/.libs/libIexMath.a \ +# Half/.libs/libHalf.a \ +# Imath/.libs/libImath.a \ +# IlmThread/.libs/libIlmThread.a ], +# [ Iex Half Imath config IlmThread ]) PKG_DEF([ladspa], [ladspa-0.4.17], [], []) @@ -337,11 +337,16 @@ PKG_3RD([mjpegtools],[yes], mpeg2enc/.libs/libmpeg2encpp.a ], [ . lavtools utils ]) -PKG_3RD([openexr],[auto], - [openexr-2.2.1], - [ IlmImf/.libs/libIlmImf.a \ - IlmImfUtil/.libs/libIlmImfUtil.a ], - [ IlmImf config ]) +PKG_3RD([openexr],[yes], + [openexr-2.4.1], + [ IlmBase/Iex/.libs/libIex.a \ + IlmBase/IexMath/.libs/libIexMath.a \ + IlmBase/Half/.libs/libHalf.a \ + IlmBase/Imath/.libs/libImath.a \ + IlmBase/IlmThread/.libs/libIlmThread.a + OpenEXR/IlmImf/.libs/libIlmImf.a \ + OpenEXR/IlmImfUtil/.libs/libIlmImfUtil.a ], + [ Iex Half Imath IlmThread IlmImf config usr/include/OpenEXR ]) --- I force-disabled openEXR probe so it will NOT pick up system headers/libs, discovered new includes demand -std=c++11 in CFLAGS :} seems to work ....
These changes look good. Thanks. and now the inevitable "but"..., these are just suggestions, but they are based on my past experiences. 1) don't leave dead code in the product unless you think it may be useful in the future. examples: the configure script is already sort of trashy, since it is the driver for a set of old products. The main reason the thirdparty design exists is that you can't trust the maintainers to not break your build. PLEASE be aware that every month any mod you make has to work on 18 platforms that cover a span of 10 years or so. Any break that is historical can stop several builds. The build system is a xen host running an embedded busybox system that only operates the build. No servers, no installed extras. It operates 3 sets of build iterators. If any of them fail, more passes (4,5,...). Each pass is risky, since it is almost always some kind of emergency patch, and usually downgrades the results. Another example, /usr/X11R7/lib has not been around for a while on most platforms. It also as permuted variants /usr/lib/X11 /usr/share/X11/ etc. If the change is really needed for a particular platform, then it may need to be "specialized". 2) I am not sure, but it looks like there is a new version of OpenEXR (2.4.1). I tried it, but it requires the a very recent version of cmake. Currently, there seems to be a struggle to replace autotools with cmake,meson,waf ... Meson broke many builds. I rewrote the dav1d meson build as a makefile, and tried to give it to the developers, but they declined to carry it. Every time they tweak the build, I have to mod the makefile. Not nice. And now the suggestion, If you are going to refactor the OpenEXR build, please see if it is possbile to get it to work with the more recent version. It is not essential to make it work, since it is already working with a usable version, but keeping up with 40 or so libraries is a major task, and maintenance is continuous. Try to make sure that the work you do will be good for as long as possible. 3) I personally wish to thank you (and all of you) who have helped to improve the result. It has always been a curiosity that almost all of the technical help is not from any "techy" component, (eg. google, apple, adobe, ...) but from real users that are just plain interested in having something nice to use. It is highly appreciated for your work on a large section of source code/libraries. Thank you. gg PS. The documentation rework is just outstanding. On Wed, Mar 18, 2020 at 6:07 AM Andrew Randrianasulu < [email protected]> wrote:
Only configure.ac patch this time ..
diff --git a/cinelerra-5.1/configure.ac b/cinelerra-5.1/configure.ac index f10af67..7375fa9 100644 --- a/cinelerra-5.1/configure.ac +++ b/cinelerra-5.1/configure.ac @@ -8,7 +8,7 @@ AC_LANG_CPLUSPLUS AC_LANG_C AC_PROG_CXX
-CFG_CFLAGS+=" -fno-omit-frame-pointer -fno-math-errno -fno-signed-zeros" +CFG_CFLAGS+=" -std=c++11 -fno-omit-frame-pointer -fno-math-errno -fno-signed-zeros" CFG_CFLAGS+=" -pthread -Wall" # misguided pedantic warnings # this is extra work, not a gain... @@ -239,14 +239,14 @@ PKG_3RD([giflib],[yes], libutil.a ], [ . ])
-PKG_3RD([ilmbase],[auto], - [ilmbase-2.2.1], - [ Iex/.libs/libIex.a \ - IexMath/.libs/libIexMath.a \ - Half/.libs/libHalf.a \ - Imath/.libs/libImath.a \ - IlmThread/.libs/libIlmThread.a ], - [ Iex Half Imath config IlmThread ]) +#PKG_3RD([ilmbase],[auto], +# [ilmbase-2.2.1], +# [ Iex/.libs/libIex.a \ +# IexMath/.libs/libIexMath.a \ +# Half/.libs/libHalf.a \ +# Imath/.libs/libImath.a \ +# IlmThread/.libs/libIlmThread.a ], +# [ Iex Half Imath config IlmThread ])
PKG_DEF([ladspa], [ladspa-0.4.17], [], [])
@@ -337,11 +337,16 @@ PKG_3RD([mjpegtools],[yes], mpeg2enc/.libs/libmpeg2encpp.a ], [ . lavtools utils ])
-PKG_3RD([openexr],[auto], - [openexr-2.2.1], - [ IlmImf/.libs/libIlmImf.a \ - IlmImfUtil/.libs/libIlmImfUtil.a ], - [ IlmImf config ]) +PKG_3RD([openexr],[yes], + [openexr-2.4.1], + [ IlmBase/Iex/.libs/libIex.a \ + IlmBase/IexMath/.libs/libIexMath.a \ + IlmBase/Half/.libs/libHalf.a \ + IlmBase/Imath/.libs/libImath.a \ + IlmBase/IlmThread/.libs/libIlmThread.a + OpenEXR/IlmImf/.libs/libIlmImf.a \ + OpenEXR/IlmImfUtil/.libs/libIlmImfUtil.a ], + [ Iex Half Imath IlmThread IlmImf config usr/include/OpenEXR ])
---
I force-disabled openEXR probe so it will NOT pick up system headers/libs, discovered new includes demand -std=c++11 in CFLAGS :}
seems to work .... -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Wednesday 18 March 2020 18:00:06 Good Guy написал(а):
These changes look good. Thanks. and now the inevitable "but"..., these are just suggestions, but they are based on my past experiences.
1) don't leave dead code in the product unless you think it may be useful in the future. examples: the configure script is already sort of trashy, since it is the driver for a set of old products. The main reason the thirdparty design exists is that you can't trust the maintainers to not break your build. PLEASE be aware that every month any mod you make has to work on 18 platforms that cover a span of 10 years or so.
Oh, 10 years old systems hardly have c++11 compiler, I'm afraid :/
Any break that is historical can stop several builds. The build system is a xen host running an embedded busybox system that only operates the build. No servers, no installed extras. It operates 3 sets of build iterators. If any of them fail, more passes (4,5,...). Each pass is risky, since it is almost always some kind of emergency patch, and usually downgrades the results. Another example, /usr/X11R7/lib has not been around for a while on most platforms. It also as permuted variants /usr/lib/X11 /usr/share/X11/ etc. If the change is really needed for a particular platform, then it may need to be "specialized".
Yes, /usr/X11R7 is local artefact, feel free to ignore (I can try to make patch without any of my changes yet.)
2) I am not sure, but it looks like there is a new version of OpenEXR (2.4.1). I tried it, but it requires the a very recent version of cmake. Currently, there seems to be a struggle to replace autotools with cmake,meson,waf ... Meson broke many builds.
yeah ... not sure if anything can be done about it. I have it mostly for mesa3d. But lately gimp/gegl started to require it, too ... And meson itself want python3, and rebuilding everything-python was a bit of chore .....
I rewrote the dav1d meson build as a makefile, and tried to give it to the developers, but they declined to carry it. Every time they tweak the build, I have to mod the makefile. Not nice. And now the suggestion, If you are going to refactor the OpenEXR build, please see if it is possbile to get it to work with the more recent version.
More recent as ? I think 2.4.1 was latest ..
It is not essential to make it work, since it is already working with a usable version, but keeping up with 40 or so libraries is a major task, and maintenance is continuous. Try to make sure that the work you do will be good for as long as possible.
Yeah .. if upstream openEXR removes this way to build their stuff - we are broken ....
3) I personally wish to thank you (and all of you) who have helped to improve the result. It has always been a curiosity that almost all of the technical help is not from any "techy" component, (eg. google, apple, adobe, ...) but from real users that are just plain interested in having something nice to use. It is highly appreciated for your work on a large section of source code/libraries. Thank you.
Well, *thank you*, because without your work any big modification of this codebase ... next to impossible :/ (at least none pulled it off yet, in all those years)
gg PS. The documentation rework is just outstanding.
On Wed, Mar 18, 2020 at 6:07 AM Andrew Randrianasulu < [email protected]> wrote:
Only configure.ac patch this time ..
diff --git a/cinelerra-5.1/configure.ac b/cinelerra-5.1/configure.ac index f10af67..7375fa9 100644 --- a/cinelerra-5.1/configure.ac +++ b/cinelerra-5.1/configure.ac @@ -8,7 +8,7 @@ AC_LANG_CPLUSPLUS AC_LANG_C AC_PROG_CXX
-CFG_CFLAGS+=" -fno-omit-frame-pointer -fno-math-errno -fno-signed-zeros" +CFG_CFLAGS+=" -std=c++11 -fno-omit-frame-pointer -fno-math-errno -fno-signed-zeros" CFG_CFLAGS+=" -pthread -Wall" # misguided pedantic warnings # this is extra work, not a gain... @@ -239,14 +239,14 @@ PKG_3RD([giflib],[yes], libutil.a ], [ . ])
-PKG_3RD([ilmbase],[auto], - [ilmbase-2.2.1], - [ Iex/.libs/libIex.a \ - IexMath/.libs/libIexMath.a \ - Half/.libs/libHalf.a \ - Imath/.libs/libImath.a \ - IlmThread/.libs/libIlmThread.a ], - [ Iex Half Imath config IlmThread ]) +#PKG_3RD([ilmbase],[auto], +# [ilmbase-2.2.1], +# [ Iex/.libs/libIex.a \ +# IexMath/.libs/libIexMath.a \ +# Half/.libs/libHalf.a \ +# Imath/.libs/libImath.a \ +# IlmThread/.libs/libIlmThread.a ], +# [ Iex Half Imath config IlmThread ])
PKG_DEF([ladspa], [ladspa-0.4.17], [], [])
@@ -337,11 +337,16 @@ PKG_3RD([mjpegtools],[yes], mpeg2enc/.libs/libmpeg2encpp.a ], [ . lavtools utils ])
-PKG_3RD([openexr],[auto], - [openexr-2.2.1], - [ IlmImf/.libs/libIlmImf.a \ - IlmImfUtil/.libs/libIlmImfUtil.a ], - [ IlmImf config ]) +PKG_3RD([openexr],[yes], + [openexr-2.4.1], + [ IlmBase/Iex/.libs/libIex.a \ + IlmBase/IexMath/.libs/libIexMath.a \ + IlmBase/Half/.libs/libHalf.a \ + IlmBase/Imath/.libs/libImath.a \ + IlmBase/IlmThread/.libs/libIlmThread.a + OpenEXR/IlmImf/.libs/libIlmImf.a \ + OpenEXR/IlmImfUtil/.libs/libIlmImfUtil.a ], + [ Iex Half Imath IlmThread IlmImf config usr/include/OpenEXR ])
---
I force-disabled openEXR probe so it will NOT pick up system headers/libs, discovered new includes demand -std=c++11 in CFLAGS :}
seems to work .... -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Wednesday 18 March 2020 18:00:06 Good Guy написал(а):
These changes look good. Thanks. and now the inevitable "but"..., these are just suggestions, but they are based on my past experiences.
1) don't leave dead code in the product unless you think it may be useful in the future.
Well, removed ilmbase from both configure.ac and thirparty/Makefile If you decide -stdc+11 requirement is NOT show stopper, then you can try to apply those and two other patches, also attached this time, because without them nothing will work put openexr-2.4.1 patches into thirdparty/src, put 2.4.1 tarball there, too (you may want to repack it, or I can find xz version ...): https://sources.voidlinux.org/openexr-2.4.1/ sha256sum openexr-2.4.1.tar.gz 3ebbe9a8e67edb4a25890b98c598e9fe23b10f96d1416d6a3ff0732e99d001c1 openexr-2.4.1.tar.gz matches with sha256sum provideed at this page: https://www.freshports.org/graphics/openexr Try on oldest system first? (due to c++11 req. it may fail first).
examples: the configure script is already sort of trashy, since it is the driver for a set of old products. The main reason the thirdparty design exists is that you can't trust the maintainers to not break your build. PLEASE be aware that every month any mod you make has to work on 18 platforms that cover a span of 10 years or so. Any break that is historical can stop several builds. The build system is a xen host running an embedded busybox system that only operates the build. No servers, no installed extras. It operates 3 sets of build iterators. If any of them fail, more passes (4,5,...). Each pass is risky, since it is almost always some kind of emergency patch, and usually downgrades the results. Another example, /usr/X11R7/lib has not been around for a while on most platforms. It also as permuted variants /usr/lib/X11 /usr/share/X11/ etc. If the change is really needed for a particular platform, then it may need to be "specialized".
2) I am not sure, but it looks like there is a new version of OpenEXR (2.4.1). I tried it, but it requires the a very recent version of cmake. Currently, there seems to be a struggle to replace autotools with cmake,meson,waf ... Meson broke many builds. I rewrote the dav1d meson build as a makefile, and tried to give it to the developers, but they declined to carry it. Every time they tweak the build, I have to mod the makefile. Not nice. And now the suggestion, If you are going to refactor the OpenEXR build, please see if it is possbile to get it to work with the more recent version. It is not essential to make it work, since it is already working with a usable version, but keeping up with 40 or so libraries is a major task, and maintenance is continuous. Try to make sure that the work you do will be good for as long as possible.
3) I personally wish to thank you (and all of you) who have helped to improve the result. It has always been a curiosity that almost all of the technical help is not from any "techy" component, (eg. google, apple, adobe, ...) but from real users that are just plain interested in having something nice to use. It is highly appreciated for your work on a large section of source code/libraries. Thank you.
gg PS. The documentation rework is just outstanding.
On Wed, Mar 18, 2020 at 6:07 AM Andrew Randrianasulu < [email protected]> wrote:
Only configure.ac patch this time ..
diff --git a/cinelerra-5.1/configure.ac b/cinelerra-5.1/configure.ac index f10af67..7375fa9 100644 --- a/cinelerra-5.1/configure.ac +++ b/cinelerra-5.1/configure.ac @@ -8,7 +8,7 @@ AC_LANG_CPLUSPLUS AC_LANG_C AC_PROG_CXX
-CFG_CFLAGS+=" -fno-omit-frame-pointer -fno-math-errno -fno-signed-zeros" +CFG_CFLAGS+=" -std=c++11 -fno-omit-frame-pointer -fno-math-errno -fno-signed-zeros" CFG_CFLAGS+=" -pthread -Wall" # misguided pedantic warnings # this is extra work, not a gain... @@ -239,14 +239,14 @@ PKG_3RD([giflib],[yes], libutil.a ], [ . ])
-PKG_3RD([ilmbase],[auto], - [ilmbase-2.2.1], - [ Iex/.libs/libIex.a \ - IexMath/.libs/libIexMath.a \ - Half/.libs/libHalf.a \ - Imath/.libs/libImath.a \ - IlmThread/.libs/libIlmThread.a ], - [ Iex Half Imath config IlmThread ]) +#PKG_3RD([ilmbase],[auto], +# [ilmbase-2.2.1], +# [ Iex/.libs/libIex.a \ +# IexMath/.libs/libIexMath.a \ +# Half/.libs/libHalf.a \ +# Imath/.libs/libImath.a \ +# IlmThread/.libs/libIlmThread.a ], +# [ Iex Half Imath config IlmThread ])
PKG_DEF([ladspa], [ladspa-0.4.17], [], [])
@@ -337,11 +337,16 @@ PKG_3RD([mjpegtools],[yes], mpeg2enc/.libs/libmpeg2encpp.a ], [ . lavtools utils ])
-PKG_3RD([openexr],[auto], - [openexr-2.2.1], - [ IlmImf/.libs/libIlmImf.a \ - IlmImfUtil/.libs/libIlmImfUtil.a ], - [ IlmImf config ]) +PKG_3RD([openexr],[yes], + [openexr-2.4.1], + [ IlmBase/Iex/.libs/libIex.a \ + IlmBase/IexMath/.libs/libIexMath.a \ + IlmBase/Half/.libs/libHalf.a \ + IlmBase/Imath/.libs/libImath.a \ + IlmBase/IlmThread/.libs/libIlmThread.a + OpenEXR/IlmImf/.libs/libIlmImf.a \ + OpenEXR/IlmImfUtil/.libs/libIlmImfUtil.a ], + [ Iex Half Imath IlmThread IlmImf config usr/include/OpenEXR ])
---
I force-disabled openEXR probe so it will NOT pick up system headers/libs, discovered new includes demand -std=c++11 in CFLAGS :}
seems to work .... -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
This OpenEXR package is a "bag of worms" -- weird, hard, and worse package to integrate in Cinelerra. GG has taken your patches, made quite a few changes, and got it to work at 2.4.1. Tomorrow he will test to see how it does on the 18+ distros to see if it will work for the monthly builds. Meanwhile, I think he has come to the conclusion that it is not worthwhile to upgrade it any more because there do not seem to be any gains in doing so -- there releases seem to be only code cleanup but not no features whatsoever. Will see if it works for the monthly builds, and then probably never again will be upgraded. gg/phyllis On Wed, Mar 18, 2020 at 9:35 AM Andrew Randrianasulu < [email protected]> wrote:
В сообщении от Wednesday 18 March 2020 18:00:06 Good Guy написал(а):
These changes look good. Thanks. and now the inevitable "but"..., these are just suggestions, but they are based on my past experiences.
1) don't leave dead code in the product unless you think it may be useful in the future.
Well, removed ilmbase from both configure.ac and thirparty/Makefile
If you decide -stdc+11 requirement is NOT show stopper, then you can try to apply those and two other patches, also attached this time, because without them nothing will work
put openexr-2.4.1 patches into thirdparty/src, put 2.4.1 tarball there, too (you may want to repack it, or I can find xz version ...):
https://sources.voidlinux.org/openexr-2.4.1/
sha256sum openexr-2.4.1.tar.gz 3ebbe9a8e67edb4a25890b98c598e9fe23b10f96d1416d6a3ff0732e99d001c1 openexr-2.4.1.tar.gz
matches with sha256sum provideed at this page: https://www.freshports.org/graphics/openexr
Try on oldest system first? (due to c++11 req. it may fail first).
examples: the configure script is already sort of trashy, since it is the driver for a set of old products. The main reason the thirdparty design exists is that you can't trust the maintainers to not break your build. PLEASE be aware that every month any mod you make has to work on 18 platforms that cover a span of 10 years or so. Any break that is historical can stop several builds. The build system is a xen host running an embedded busybox system that only operates the build. No servers, no installed extras. It operates 3 sets of build iterators. If any of them fail, more passes (4,5,...). Each pass is risky, since it is almost always some kind of emergency patch, and usually downgrades the results. Another example, /usr/X11R7/lib has not been around for a while on most platforms. It also as permuted variants /usr/lib/X11 /usr/share/X11/ etc. If the change is really needed for a particular platform, then it may need to be "specialized".
2) I am not sure, but it looks like there is a new version of OpenEXR (2.4.1). I tried it, but it requires the a very recent version of cmake. Currently, there seems to be a struggle to replace autotools with cmake,meson,waf ... Meson broke many builds. I rewrote the dav1d meson build as a makefile, and tried to give it to the developers, but they declined to carry it. Every time they tweak the build, I have to mod the makefile. Not nice. And now the suggestion, If you are going to refactor the OpenEXR build, please see if it is possbile to get it to work with the more recent version. It is not essential to make it work, since it is already working with a usable version, but keeping up with 40 or so libraries is a major task, and maintenance is continuous. Try to make sure that the work you do will be good for as long as possible.
3) I personally wish to thank you (and all of you) who have helped to improve the result. It has always been a curiosity that almost all of the technical help is not from any "techy" component, (eg. google, apple, adobe, ...) but from real users that are just plain interested in having something nice to use. It is highly appreciated for your work on a large section of source code/libraries. Thank you.
gg PS. The documentation rework is just outstanding.
On Wed, Mar 18, 2020 at 6:07 AM Andrew Randrianasulu < [email protected]> wrote:
Only configure.ac patch this time ..
diff --git a/cinelerra-5.1/configure.ac b/cinelerra-5.1/configure.ac index f10af67..7375fa9 100644 --- a/cinelerra-5.1/configure.ac +++ b/cinelerra-5.1/configure.ac @@ -8,7 +8,7 @@ AC_LANG_CPLUSPLUS AC_LANG_C AC_PROG_CXX
-CFG_CFLAGS+=" -fno-omit-frame-pointer -fno-math-errno -fno-signed-zeros" +CFG_CFLAGS+=" -std=c++11 -fno-omit-frame-pointer -fno-math-errno -fno-signed-zeros" CFG_CFLAGS+=" -pthread -Wall" # misguided pedantic warnings # this is extra work, not a gain... @@ -239,14 +239,14 @@ PKG_3RD([giflib],[yes], libutil.a ], [ . ])
-PKG_3RD([ilmbase],[auto], - [ilmbase-2.2.1], - [ Iex/.libs/libIex.a \ - IexMath/.libs/libIexMath.a \ - Half/.libs/libHalf.a \ - Imath/.libs/libImath.a \ - IlmThread/.libs/libIlmThread.a ], - [ Iex Half Imath config IlmThread ]) +#PKG_3RD([ilmbase],[auto], +# [ilmbase-2.2.1], +# [ Iex/.libs/libIex.a \ +# IexMath/.libs/libIexMath.a \ +# Half/.libs/libHalf.a \ +# Imath/.libs/libImath.a \ +# IlmThread/.libs/libIlmThread.a ], +# [ Iex Half Imath config IlmThread ])
PKG_DEF([ladspa], [ladspa-0.4.17], [], [])
@@ -337,11 +337,16 @@ PKG_3RD([mjpegtools],[yes], mpeg2enc/.libs/libmpeg2encpp.a ], [ . lavtools utils ])
-PKG_3RD([openexr],[auto], - [openexr-2.2.1], - [ IlmImf/.libs/libIlmImf.a \ - IlmImfUtil/.libs/libIlmImfUtil.a ], - [ IlmImf config ]) +PKG_3RD([openexr],[yes], + [openexr-2.4.1], + [ IlmBase/Iex/.libs/libIex.a \ + IlmBase/IexMath/.libs/libIexMath.a \ + IlmBase/Half/.libs/libHalf.a \ + IlmBase/Imath/.libs/libImath.a \ + IlmBase/IlmThread/.libs/libIlmThread.a + OpenEXR/IlmImf/.libs/libIlmImf.a \ + OpenEXR/IlmImfUtil/.libs/libIlmImfUtil.a ], + [ Iex Half Imath IlmThread IlmImf config usr/include/OpenEXR ])
---
I force-disabled openEXR probe so it will NOT pick up system headers/libs, discovered new includes demand -std=c++11 in CFLAGS :}
seems to work .... -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Thursday 19 March 2020 06:30:14 Phyllis Smith написал(а):
This OpenEXR package is a "bag of worms" -- weird, hard, and worse package to integrate in Cinelerra. GG has taken your patches, made quite a few changes, and got it to work at 2.4.1. Tomorrow he will test to see how it does on the 18+ distros to see if it will work for the monthly builds.
If it break - I can try to search for possible solutions. I saw CentOS mentioned in documentation update - depend on version this may require some thinking and action. After all - I made this motion - therefore I should help if it broke. And yes, I tried to push this rel. early because doing this stuff at near rebuild date is .. more nerve-wrenching. Still, if it really broke more than one or two builds - I will not push upgrade for the sake of upgrade - after all, there are system libraries, and I can patch stuff locally ....
Meanwhile, I think he has come to the conclusion that it is not worthwhile to upgrade it any more because there do not seem to be any gains in doing so -- there releases seem to be only code cleanup but not no features whatsoever.
Well, if there will be more use of OpenEXR/ILMbase features/functions in Cin - then outdated lib will make life harder .... (I'm thinking about those 16-bit float functions)
Will see if it works for the monthly builds, and then probably never again will be upgraded. gg/phyllis
On Wed, Mar 18, 2020 at 9:35 AM Andrew Randrianasulu < [email protected]> wrote:
В сообщении от Wednesday 18 March 2020 18:00:06 Good Guy написал(а):
These changes look good. Thanks. and now the inevitable "but"..., these are just suggestions, but they are based on my past experiences.
1) don't leave dead code in the product unless you think it may be useful in the future.
Well, removed ilmbase from both configure.ac and thirparty/Makefile
If you decide -stdc+11 requirement is NOT show stopper, then you can try to apply those and two other patches, also attached this time, because without them nothing will work
put openexr-2.4.1 patches into thirdparty/src, put 2.4.1 tarball there, too (you may want to repack it, or I can find xz version ...):
https://sources.voidlinux.org/openexr-2.4.1/
sha256sum openexr-2.4.1.tar.gz 3ebbe9a8e67edb4a25890b98c598e9fe23b10f96d1416d6a3ff0732e99d001c1 openexr-2.4.1.tar.gz
matches with sha256sum provideed at this page: https://www.freshports.org/graphics/openexr
Try on oldest system first? (due to c++11 req. it may fail first).
examples: the configure script is already sort of trashy, since it is the driver for a set of old products. The main reason the thirdparty design exists is that you can't trust the maintainers to not break your build. PLEASE be aware that every month any mod you make has to work on 18 platforms that cover a span of 10 years or so. Any break that is historical can stop several builds. The build system is a xen host running an embedded busybox system that only operates the build. No servers, no installed extras. It operates 3 sets of build iterators. If any of them fail, more passes (4,5,...). Each pass is risky, since it is almost always some kind of emergency patch, and usually downgrades the results. Another example, /usr/X11R7/lib has not been around for a while on most platforms. It also as permuted variants /usr/lib/X11 /usr/share/X11/ etc. If the change is really needed for a particular platform, then it may need to be "specialized".
2) I am not sure, but it looks like there is a new version of OpenEXR (2.4.1). I tried it, but it requires the a very recent version of cmake. Currently, there seems to be a struggle to replace autotools with cmake,meson,waf ... Meson broke many builds. I rewrote the dav1d meson build as a makefile, and tried to give it to the developers, but they declined to carry it. Every time they tweak the build, I have to mod the makefile. Not nice. And now the suggestion, If you are going to refactor the OpenEXR build, please see if it is possbile to get it to work with the more recent version. It is not essential to make it work, since it is already working with a usable version, but keeping up with 40 or so libraries is a major task, and maintenance is continuous. Try to make sure that the work you do will be good for as long as possible.
3) I personally wish to thank you (and all of you) who have helped to improve the result. It has always been a curiosity that almost all of the technical help is not from any "techy" component, (eg. google, apple, adobe, ...) but from real users that are just plain interested in having something nice to use. It is highly appreciated for your work on a large section of source code/libraries. Thank you.
gg PS. The documentation rework is just outstanding.
On Wed, Mar 18, 2020 at 6:07 AM Andrew Randrianasulu < [email protected]> wrote:
Only configure.ac patch this time ..
diff --git a/cinelerra-5.1/configure.ac b/cinelerra-5.1/configure.ac index f10af67..7375fa9 100644 --- a/cinelerra-5.1/configure.ac +++ b/cinelerra-5.1/configure.ac @@ -8,7 +8,7 @@ AC_LANG_CPLUSPLUS AC_LANG_C AC_PROG_CXX
-CFG_CFLAGS+=" -fno-omit-frame-pointer -fno-math-errno -fno-signed-zeros" +CFG_CFLAGS+=" -std=c++11 -fno-omit-frame-pointer -fno-math-errno -fno-signed-zeros" CFG_CFLAGS+=" -pthread -Wall" # misguided pedantic warnings # this is extra work, not a gain... @@ -239,14 +239,14 @@ PKG_3RD([giflib],[yes], libutil.a ], [ . ])
-PKG_3RD([ilmbase],[auto], - [ilmbase-2.2.1], - [ Iex/.libs/libIex.a \ - IexMath/.libs/libIexMath.a \ - Half/.libs/libHalf.a \ - Imath/.libs/libImath.a \ - IlmThread/.libs/libIlmThread.a ], - [ Iex Half Imath config IlmThread ]) +#PKG_3RD([ilmbase],[auto], +# [ilmbase-2.2.1], +# [ Iex/.libs/libIex.a \ +# IexMath/.libs/libIexMath.a \ +# Half/.libs/libHalf.a \ +# Imath/.libs/libImath.a \ +# IlmThread/.libs/libIlmThread.a ], +# [ Iex Half Imath config IlmThread ])
PKG_DEF([ladspa], [ladspa-0.4.17], [], [])
@@ -337,11 +337,16 @@ PKG_3RD([mjpegtools],[yes], mpeg2enc/.libs/libmpeg2encpp.a ], [ . lavtools utils ])
-PKG_3RD([openexr],[auto], - [openexr-2.2.1], - [ IlmImf/.libs/libIlmImf.a \ - IlmImfUtil/.libs/libIlmImfUtil.a ], - [ IlmImf config ]) +PKG_3RD([openexr],[yes], + [openexr-2.4.1], + [ IlmBase/Iex/.libs/libIex.a \ + IlmBase/IexMath/.libs/libIexMath.a \ + IlmBase/Half/.libs/libHalf.a \ + IlmBase/Imath/.libs/libImath.a \ + IlmBase/IlmThread/.libs/libIlmThread.a + OpenEXR/IlmImf/.libs/libIlmImf.a \ + OpenEXR/IlmImfUtil/.libs/libIlmImfUtil.a ], + [ Iex Half Imath IlmThread IlmImf config usr/include/OpenEXR ])
---
I force-disabled openEXR probe so it will NOT pick up system headers/libs, discovered new includes demand -std=c++11 in CFLAGS :}
seems to work .... -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (3)
-
Andrew Randrianasulu -
Good Guy -
Phyllis Smith