Re: [lcd4linux] Re: need help with autmake, libtool and

[Ronald Landheer-C. <bly...@us...>]

On Sat, Oct 04, 2003 at 09:57:26AM +0200, Michael Reinelt wrote:
> first I want to thank you for your support!
You're welcome :)

> Ronald Landheer-Cieslak wrote:
> >The attached patch will partly fix that. What still needs fixing after this
> >patch is using Libtool to build the object files needed by DRIVERS, but 
> >that means changing configure.in to set up drivers correctly (i.e. using
> >$(OBJEXT) in stead of .o)
> >
> >The patch also re-enables Libtool in configure.in, but doesn't fix DRIVERS
> >(yet).
> 
> Ok, I applied your patch, and changed all .o to .$OBJECT in configure.in 
> (without parens!) It works, at least for me. I checked all the cnages 
> into CVS!
> 
> But there are several questions:
> - is the .$OBJEXT (instead of .$(OBJEXT) correct?
No: $(OBJEXT) is a Makefile variable, whereas $OBJEXT (or ${OBJEXT} is a shell
variable. As OBJEXT is canonically defined in the Makefile, you should use the
makefile variant.
> >I've also attached a bootstrap script for lcd4linux.
> - what the ehck is a bootstrap script?
It's the script used to launch the Autotools, to create the configure and
Makefile.in files (and libtool)
> - should it be included
>   - in CVS
Yes
>   - in the distribution tarball?
No.

> - is AM_PROG_LIBTOOL necessary in configure.in? (it's deactivated at the 
> moment)
No: it's the deprecated form of AC_PROG_LIBTOOL

> - should the local 'libtool' script be included
>   - in CVS
IMHO, no: there should be no generated files in CVS - so configure and 
Makefile.in shouldn't be there either, IMHO.
Opinions may differ rather widely on this, though, but I've found it's often
more trouble than it's worth to have generated files in CVS if you have the
sources as well.

>   - in the distribution tarball?
Yes.

> - lcd4linux (the main program) is linked against the shared 
> liblcd4linux. Is it possible to build liblcd4linux as it is now, but 
> lcd4linux as a real standalone application (without liblcd4linux?) Would 
> this make sense?
Personally, I'd go for using a shared lib, but if you don't want to, the 
easiest way to force static linking is to use the proper configure option
(--disable-shared). You can do that by default by checking for it in
configure.in and setting it to disabled of not explicitly set to enabled.
That way, the final choice is with the end user - the one that compiles his
own version - or with the packager, if there is one.

rlc