Re: Autotools and The Core

On Die , 2004-03-21 at 16:43, Meredydd wrote:
> On Sunday 21 March 2004 20:53, Rodney Dawes wrote:
> > So,
> >
> > While waiting for responses to my other mail, I installed subversion,
> > grabbed bleeding,
> Whoa. Just FYI, if you're developing a component, you should be working 
> on trunk. Back-merging patches against bleeding or alpha trees tends to 
> be a bit of a pain - if you want semi-stable code for a particular 
> component, grab bleeding or alpha for that component only (you can even 
> do this in the same tree - check the subversion docs).

Well. I can't seem to grab only "core" for example. I tried to grab just
eb-lite/core, and svn grabbed all the modules, and just put everything
under "eb-lite/core/" on my local system.

> > I do have it passing distcheck now, but there 
> > are still quite a bit of issues to deal with, mainly the static vs.
> > dynamic plug-in builds. 
> Yeah, minefield, that. I always build static, myself (less likely to 
> blow up in one's face, in my experience) - perhaps this should be the 
> default? Loadable modules are always good (I know Edward in particular 
> wants this), and we shouldn't turn them off, but to be quite honest, 
> can you imagine yourself wanting to upgrade, say, just the MSN module?

So I saw when I discovered the .mer config system. :) I'd actually
prefer to keep the dynamic modules as the default. I've never had
problems dynamic modules blowing up in my face, where the issue was
that of the underlying loading system. It has always been better for
me. And yes, I could imagine myself wanting to upgrade only the MSN
module. Though, it doesn't really matter if the module is part of the
core package. There are so many advantages to having loadable modules
for this sort of thing, that I'd rather not waste time arguing it, and
just fix the build system to work properly. :)

> > Anyway, I noticed that there is a lot of 
> > weirdness for building the core on win32 in the Makefile.am files.
> > Some parts were commented out, some parts add libraries, that we
> > seemingly don't check for in the core configure script, etc... And,
> > so, I was wondering what the state of the core is on win32,
> That's Edward's patch, and I'm afraid I haven't a clue. A while ago, I 
> essentially made the decision that any part of the core within MINGW 
> #ifdefs was Edward's jurisdiction, and that he was as free to commit to 
> them as, say, Karine is to ebnc, so I haven't even reviewed most of 
> these changes.

Hrmm. OK. AFAICT, most of this shouldn't be here.

> > and why we need to require glib2 there,
> Uhm...pass.
> 
> > but we don't want to require it 
> > on unix.
> Damn right, I really quite dislike glib :-P
> The core should depend on as little as possible.

What is your dislike with glib? I could see the core source being
reduced heftily by using it. :) PAM even requires glib these days.
Anyway, just wondering why you think this way.

> > I'd like just go through and make the whole build sane right 
> > off the bat, than just making it pass distcheck, and then dealing
> > with the other problems later.
> Sounds cool. Do keep us posted!
> 
> > Thanks. 
> Thank-*you*.
> 
> Meredydd

:)

-- dobey