[Pkg-ace-devel] Closing RC bugs

[Pau Garcia i Quiles]

On Tue, Nov 10, 2009 at 11:34 PM, Thomas Girard <thomas.g.girard at free.fr> wrote:
> Pau Garcia i Quiles wrote:
>>
>> I've been trying to get ACE 5.7.4 to build but I didn't succeed, the
>> generated 'configure' fails.
>>
>> I've uploaded what I have to http://www.elpauer.org/tmp/ace
>>
>> My last try with 5.6.9, months ago, is also still there. That one
>> builds but as I said in May, some new binary packages need to be
>> created, etc ( see
>>
>> http://lists.alioth.debian.org/pipermail/pkg-ace-devel/2009-May/001819.html
>> )
>
> Ok. I'm still working on fixing RC bugs for 5.6.3. I'll have a look at
> your work after.
>
>> In the end, I think we should move the buildsystem from autotools to
>> the traditional way (
>>
>> http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/ACE-INSTALL.html#unix_traditional
>> ), as autotools seems to receive very few love from upstream.
>
> Well, my initial goal was to use the autoconf build mechanism in Debian
> so that:
>  - no arch specific issues raised
>  - GNU/kFreeBSD and GNU/Hurd work as well
>  - it would improve autoconf support in ACE+TAO (I've contributed some
> ACE+TAO autoconf macros)
>
> Now, given my workload, it seems it was too ambitious. Anyway I still
> think that's a goal we should aim. Therefore I would suggest to make it
> possible to use both traditional and autoconf based mechanism.
>
> Pros:
>  - Easier to adapt and deliver to Debian new ACE+TAO releases
> Cons:
>  - GNU/Hurd and GNU/kFreeBSD support would take more time
>  - autoconf support for ACE+TAO no longer improving
>
> Clearly pros outweigh cons, so let's go for it.

Given how awful is the traditional buildsystem, I'd rather use autotools too.

Problem is I'm not sure we can maintain it. It's totally unmaintained
upstream and every time someone says in the ace-users mailing list "I
have trouble with autotools", the standard answer is "use the
traditional way to build ACE" :-(

>> It'd be nice if patches were better documented, too. Many of the
>> patches, I don't know why they are required :-(
>
> debian/patches/*.dpatch files should have a comment line (starting with
> '## DP:'). But they are probably too terse, I've been working on these
> packages alone for too long. Which ones would you like to see
> documented?

For instance:

* 02-fltk-no-gl.dpatch - Why not linking against FLTK GL? Because that
requires OpenGL and on some systems it won't be available and FLTK is
not smart enough to fall back to software rendering? (I don't really
know FLTK)

* 02-qt4.dpatch - Why Qt4? While no longer supported by Nokia, Qt3 is
still available on Debian and it's what upstream provides

* 04-reduce-opt.dpatch - Why no optimization at all? Not even O2 ?

* 16-skip-apps.dpatch - Why avoid those apps and not others?

I'm sure there's a good reason for each and every patch but...

>>> Do you have an alioth account?
>>
>> Yes, I do. It's pgquiles-guest
>
> Good. I am currently working on branches/5.6.3. If you familiar with
> SVN and willing to join the pkg-ace team then just tell me and the trunk
> will be yours...

OK. I can't promise I will get something working, though. My autotools
skills are limited (I'm more of a CMake guy :-))

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)