Andrew Randrianasulu <randrianasulu%gmail.com@localhost> writes:
> сб, 6 июл. 2024 г., 15:57 Greg Troxel <gdt%lexort.com@localhost>:
>
>> Andrew Randrianasulu <randrianasulu%gmail.com@localhost> writes:
>>
>> > I wonder when I should enable additional architectures for testing?
>> Before
>> > package enters (hopefully) main pkgsrc tree or after?
>>
>> I don't follow "enable". Generally, a package should run on any
>> architecture and if not it's a bug. If it's known not to run on some
>> system, then BROKEN_ON for that system, written narrowly to only include
>> what is known to fail, is ok.
>
> I do not have many systems, definitely not AIX or Solaris, or much of
> non-x86 ....
I think we are not understanding each other.
I am trying to say that if you have a package, and you have never run it
on AIX, then agreed that you have no idea that if you tried, it would
build or work. That's ok.
It is not ok to mark it BROKEN_ON+=AIX with reason "I haven't tried it
and it might not work".
Right now you have ONLY_FOR_PLATFORM to NetBSD and two CPU types and no
justification.
> We use somewhat strange feature when number of png files concatenated
> together and put as .o object in final executable. This is ... not very
> portable (I was unable to make it works on macos x) and we also use /proc
> filesystem (so OpenBSD probably out).
OK, but what you are describing are basically upstream ("we" means that
is you I guess) bugs.
> Also, right now env. variable BSD=1 (this signals to our build system to
> omit few features related to signals and thread debugging) is not
> conditional in Makefile. (hopefully easy to fix, but again, I do not have
> working pkgsrc outside of single VM.)
This is what autoconf is for :-) But I would suggest that you first make
the program work on NetBSD, not with pkgsrc. I always say to people
when a package does not work: if you follow the upstream build
instructions by hand, do you get a working program? If so, then there
is a pkgsrc bug. If not, then there is an upstream bug.
That said, pkgsrc does work around upstream bugs. But, that is working
around, not Plan A.
> Well, as I said source builds for me on Linux/ppc but does not start. So, I
> completely rely on non-automatic reports in this area ...
I do not understand that.
building on Linux/ppc works. Running unfortunately not. Since then I fixed (hopefully) one alignment bug, but may be there are others I am not aware about.
> Just to clarify, you think I should remove _ONLY_FOR_PLATFORM_= line from
> Makefile, let autobuilders do their thing, then re-add BROKEN_ON based on
> result? Where I can see list of platforms where autobuild fails for my
> specific package? Should I somewhat manually trigger builds on server(s)
> somewhere?
Yes, you should remove it. But there is no autobuild on wip.
Stepping back:
are you the upstream? If so, I think you should fix the upstream
package to straightforwardly build and work as portably as possible on
as many systems as possible, by avoiding non-portable things. And
then it will be easy to package.
Yes, I am part of upstream. Unfortunately, I am not that skilled and our real developer died 4 years ago.
Usually we were trying to keep our source organized the same as Cinelerra-HV (our historical root) for ease of merging changes from there. This includes strange idea of "pngs in object file as part of main executable".
I tried to do it differently and failed
But cingg by itself definitely was buildable on netbsd/i386, I was using that before I switched my effort towards package.
cd cinelerra-5.1
run
blds/netbsd.bld
it should give you single-user (local to build tree) build in $CIN_ROOT/bin
under X11 run this binary and program should show startup messages and open four windows.
Another part of our unportability related to way we use /proc for getting our own executable name/path. Is there more portable way to do so?