David: your feedback is very much appreciated and we will do what we can to resolve the issues you brought up as best as possible, but if it is still too burdensome for you, you have to consider whether or not you feel it is worth your time.
We do monthly builds for Arch, Centos, Debian 8 & 9, Fedora 26-29, Leap/Suse 15, 42 & 10bit, Mint 18 & 19, Slackware 32 and 64 bit, Ubuntu 14, 16, 17, 18 & 32bit v14, and FreeBSD. The build procedures we use have to work for all of these as automatically as possible using XEN. Even then we still have to do some manual work.
GG's expertise is in programming languages and writing build scripts was only something he had to do to get cinelerra-gg software usable. It would be really great to have a person whose expertise is in writing build scripts help out and still leave our XEN working.
> As it turns out, it is not all that hard to make a system deliverable
> build using the following procedure:
In fact, 'not that hard' would be:
git clone https://aur.archlinux.org/cinelerrag-gg.git
cd cinelerra-gg
makepkg -LCcf
This build design would be the one that would fit "your" needs. Every month, I build:
ub14/deb ub18/deb ub17/deb ub16/deb leap14/rpm leap15/rpm ubuntu/deb mint18/deb \
fc26/rpm fc27/rpm fc28/rpm debian9i/deb debian8/deb debian9/deb arch/arch mint17/deb \
freebsd slk32 slk64
As you can see, there are several build designs that need to be accommodated. Your
suggestion does bare the fact that it is not as easy as it can be for you to do a bulid.
I can add the PKGBUILD I provided (or similar, if you have recommended changes) as
a file in the top level directory, so that it can operate as you wish. My build procedures
are in the "blds" directory. In fact, the PKGBUILD you have is just a simple composition of
blds/arch.bld and the monthly PKGBUILD which I normally use for each monthly build.
The dependency list is not customized to the vastly reduced build target design needed
when the thirdparty libraries are not built, where the build must rely only on system libraries.
If you have all of the demands needed to change the build design limit, you should remove
the --without features that can be removed. I am not very familiar with the current state
of the arch library series, and I think that you are vastly more qualified to make this kind
of judgement. If you can create a recommended PKGBUILD, I will be happy to add it to
the top level directory as you suggest.
Why is the --disable-static-build option to configure not documented,
the various --disable-option possibilities are though?
Disable static build defaults to "auto", which is no for system builds.
It is listed in ./configure --help. It did not need to be specified, but I put it in as a redundant
specification just to indicate that non-static builds are available. In fact, each monthly build
includes system packages that include thirdparty static, and are dynamically linked to most
normally available system libraries. The wide configuration of ffmpeg prevents just blasting
in a "one size fits all" type build config. I am only one good-guy after all.
That is not what pkgrel [1] is for (hence my quote on versioning)!
What you want is a consistent versioning, reflected in pkgver [2].
These are monthly build ids, not any trick canonical naming system. As before, if you can
identify what you would like, I will be happy to add it as the top level build design for arch.
You will want to use devtools for that to achieve reproducibility.
Also, there's no reason to use sudo here. Additionally, makepkg has a
builtin log feature ( -L ), so there is no need for piping to tee
manually.
The data I provided was to illustrate that it is "not difficult" to produce a build. I did not say
it would be "perfect" for your needs. I am definitely not an expert on arch system build
designs. Any polish you can add would be widely appreciated.
checking whether X_HAVE_UTF8_STRING is declared... no
configure: error: Cinelerra requires utf8 support in X Windows.
Strange, it is in /usr/include/X11/Xlib.h at line 70
and the autoconf test in configure looks good and succeeds on my arch system.
I have no idea why your getting this problem. I would check your system include
/usr/include/X11/Xlib.h for this line, and check the configure output of autogen.sh
to see if the test looks like:
ac_fn_c_check_decl "$LINENO" "X_HAVE_UTF8_STRING" "ac_cv_have_decl_X_HAVE_UTF8_STRING" "#include <X11/Xlib.h>
"
if test "x$ac_cv_have_decl_X_HAVE_UTF8_STRING" = xyes; then :
else
no_utf=yes
fi
Works for me.
There are `--without-firewire --without-dv --without-dvb
--without-video4linux2`, but the package dependencies are still pulled
in in depends (also, that array should be named lower-case, not all
upper case letters).
It is only recently that ffmpeg libraries have been widely published on mainstream distros.
The blds/*.bld scripts were created in haste, from a template build procedure that relied on
a reduced recipe. The --without feature set is more of a reflex action. I did not spend
a lot of time on any particular build design to determine the boundary of supported features.
It is definitely the case that using the thirdparty build when possible is more stable than most
system library sets. Heck, libxft is everywhere and is very dilapidated. I would recommend
that you use the thirdparty build if possbile for two reasons... 1) the version is known, current
and is more tested with this product. 2) in the event of a bug, the debug info can be easily
accessed since the source is always consistent to the binary. This is not easy to produce,
but... after using this for years I can say unequivocally that it is better. Also, what ARRAY?
To get clarification about the dependencies, as this really doesn't jump
at me: It seems to be okay to disable libzmpeg and commercial, but what
is the latter actually pulling in/providing?
I assume, that people would want something like lv2 integration. What is
the rationale behind it being disabled?
A couple of years ago, I was so dismayed over rude TV commercials, that I began to
implement an "ad-blocker" for video. I mostly got it to work, but it requires too much
effort to maintain a database of signature clips of ads to block. I left it because it provides
a means to access reduced mpeg images in real time for ad suppression. It still needs
work, but the framework is valuable, and so it persists waiting for someone to make a
billion bucks by implementing an ad blocker for commercial TV.
The reason lv2 is disabled is that I ported lv2 at about the same time I created the *.bld
scripts. At the time, the lv2 support was pretty shaky. I opted to leave it out, but now it
may be ok to add it. It has not been tested at all in this way. It may or may not be possible.
My experience with lv2 was quite variable. some work well, some don't.
Another thing I found out is, that for ladspa integration, there's
always the local version used, even if I provide `--disable-ladspa`, it
is set to "forced".
When thirdparty is disabled, it is not built. I will fix the message in the ./configure output
to not indicate that it is in the build.
> TO TEST: pacman -U ./cin-5.1-20181129-arch-x86_64.pkg.tar.xz (or
> whatever) then type: cin
Thanks for the suggestion.
I really appreciate you took the time to look hard at this. Hope to hear from you soon.
gg