[Pkg-ace-devel] Closing RC bugs

[Thomas Girard]

Pau Garcia i Quiles wrote:
>> 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" :-( 

Yes. It requires a lot of man power (or fundings).

We can make the package build process default to traditional way, and
have an DEB_BUILD_OPTIONS option for the adventurous autotools way.

>>> 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... 

I'll document these, as well as adding a README.source explaining how
to rebuild the package.

>>>> 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 :-))

You should now be able to commit to SVN (at least you're in the alioth 
group now). Please let me know if you can't.

Hmmm, maybe you could write CMake bindings for MPC so that we can get
rid of autotools nightmare ;-) ?

Whenever you feel like you've something ready for review, or if you're
stuck, please let me know. I can't tell when will be the next free slot,
but I'll try to get ACE+TAO the attention it deserves.

Regards,

Thomas