EDE: make project shared objects

[Sascha Wilde-2]

The following patch addresses a bunch of issues:
- Some incarnations of libtool (namely the one in Debian Lenny) need
  --tag even in this simple case
- We use the libtool .lo object extension, so we no longer interfere
  with the default rules for non shared objects
- Added missing -c for object generation
- Removed LTLINK var definition from compiler, this belongs only to the
  linker definition.
- Fixed the linker definition: there was CPP used, but linking is not
  done by the preprocessor...  :)


diff -r 95a232c6691b lisp/cedet/ede/proj-shared.el
--- a/lisp/cedet/ede/proj-shared.el Wed Oct 28 17:41:17 2009 +0100
+++ b/lisp/cedet/ede/proj-shared.el Thu Oct 29 15:48:38 2009 +0100
@@ -71,18 +71,19 @@
  "ede-c-shared-compiler-libtool"
  :name "libtool"
  :variables '(("LIBTOOL" . "libtool")
-      ("LTCOMPILE" . "$(LIBTOOL) --mode=compile $(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)")
-      ("LTLINK" . "$(LIBTOOL) --mode=link $(CC) $(CFLAGS) $(LDFLAGS) -L. -o $@")
+      ("LTCOMPILE" .
+       "$(LIBTOOL) --tag=CC --mode=compile $(CC) -c $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)")
       )
  :rules (list (ede-makefile-rule
        "cc-inference-rule-libtool"
-       :target "%.o"
+       :target "%.lo"
        :dependencies "%.c"
        :rules '("@echo '$(LTCOMPILE) -o $@ $<'; \\"
  "$(LTCOMPILE) -o $@ $<"
  )
        ))
  :autoconf '("AC_PROG_LIBTOOL")
+ :objectextention ".lo"
  )
   "Compiler for C sourcecode.")
 
@@ -94,7 +95,7 @@
    :sourcetype '(ede-source-c++)
    :variables  '(
  ("LIBTOOL" . "libtool")
- ("LTLINK" . "$(LIBTOOL) --tag=CPP --mode=link $(CPP) $(CFLAGS) $(LDFLAGS) -L. -o $@")
+ ("LTLINK" . "$(LIBTOOL) --tag=CC --mode=link $(CC) $(CFLAGS) $(LDFLAGS) -L.")
  )
    :commands '("$(LTLINK) -o $@ $^")
    :autoconf '("AC_PROG_LIBTOOL")


It should be transferred to the libtool based c++ compiler/linker
definitipon, too -- but I'm no c++ guy, so I would like to leave this to
someone who is willing/able to test it...  ;-)

FWIW: Linking against libs in make projects still doesn't work.  I'll
have a look t this next...

cheers
sascha
--
Sascha Wilde : "There are 10 types of people in the world.
             : Those who understand binary and those who don't."

[Lluis-3]

El Thu, Oct 29, 2009 at 04:01:00PM +0100, Sascha Wilde ens deleit� amb les seg�ents paraules:
[...]
> It should be transferred to the libtool based c++ compiler/linker
> definitipon, too -- but I'm no c++ guy, so I would like to leave this to
> someone who is willing/able to test it...  ;-)

Haven't tested it, but if what you want is to conform to the rules generated by
automake, this is somewhat like:

    ("CXXLINK" . "$(LIBTOOL) --tag=CXX --mode=link $(CXXLD) $(CXXFLAGS) $(LDFLAGS)")

In fact, the line in an automake is:

    CXXLINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
        --mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) $(AM_LDFLAGS) \
        $(LDFLAGS) -o $@

Lluis

--
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

[Sascha Wilde-2]

Sascha Wilde <wilde@...> wrote:

> The following patch addresses a bunch of issues:
[...]
Another important issue with the current code (inkluding my fixes) is,
that it only generates static libraries.

Fixing this is not trivial -- its not really hard either but it needs
some additional infrastructure:

The Makefile created by EDE make projects doesn't have any
infrastructure for installation (by convention this would be an PREFIX
variable and an install target).  But to create shared libraries libtool
needs an -rpath option, which would be normally set $(PREFIX)/lib.

Further more: the best/easiest way to install shared libraries and
dynamically linked programs is using libtool, too[0] -- so we need an
install make target, calling libtool in the right way.

> FWIW: Linking against libs in make projects still doesn't work.  I'll
> have a look t this next...

It would be best to use libtool for linking programs, too -- at least
when they are linked against shared libraries which are part of the
project.  But this also makes only sense with an install target.

sascha

[0] libtool hides the real stuff in an hidden directory .libs and
    installs only wrapper scripts in the source directory, this allows
    to test drive dynamically linked applications in the source
    directory but makes the right way of manual installation less
    obvious.
--
Sascha Wilde
We're Germans and we use Unix. That's a combination of two
demographic groups known to have no sense of humour whatsoever.
  -- Hanno Mueller in de.comp.os.unix.programming

[Stefan Monnier]

> It would be best to use libtool for linking programs, too -- at least
> when they are linked against shared libraries which are part of the
> project.  But this also makes only sense with an install target.

I do not have a strong opinion on this, but IIUC while autoconf seems to
be usually appreciated, and mostly so as well for automake (tho to
a lesser extent), libtool has many more detractors because it is a lot
more invasive.

So it might be good to support projects using libtool, but I think it
is important not to impose it.


        Stefan

[Miles Bader-2]

Stefan Monnier <monnier@...> writes:

>> It would be best to use libtool for linking programs, too -- at least
>> when they are linked against shared libraries which are part of the
>> project.  But this also makes only sense with an install target.
>
> I do not have a strong opinion on this, but IIUC while autoconf seems to
> be usually appreciated, and mostly so as well for automake (tho to
> a lesser extent), libtool has many more detractors because it is a lot
> more invasive.
>
> So it might be good to support projects using libtool, but I think it
> is important not to impose it.

The last time I attempted to use libtool, it was a huge mess; it seemed
to be trying so hard to be portable that it ended up being barely
usable.

-Miles

--
80% of success is just showing up.  --Woody Allen

[Sascha Wilde-2]

Miles Bader <miles@...> wrote:
> Stefan Monnier <monnier@...> writes:
>>> It would be best to use libtool for linking programs, too -- at least
>>> when they are linked against shared libraries which are part of the
>>> project.  But this also makes only sense with an install target.
>>
>> I do not have a strong opinion on this, but IIUC while autoconf seems to
>> be usually appreciated, and mostly so as well for automake (tho to
>> a lesser extent), libtool has many more detractors because it is a lot
>> more invasive.

While statements like this are not uncommon, I miss in many cases a
clear explanation what the actual downsides of libtool are.[0]

>> So it might be good to support projects using libtool, but I think it
>> is important not to impose it.

The current situation is that the EDE make projects don't work for
libraries at all and getting them to work is easiest achieved by using
libtool.

In a next step we could try to get it work even without libtool (EDE's
concept of selectable compiler and linker templates makes it easy to
support different strategies), BUT getting this right (including library
versioning, rpath, in place testing of dynamically linked binaries)
isn't trivial.  And getting it sufficiently portable would mean to
duplicate the affords of libtool in great lengths.  It might be
worthwhile if we could do better than libtool with respect to being less
"invasive" (for what ever that means) but I doubt its worth the trouble.

> The last time I attempted to use libtool, it was a huge mess; it seemed
> to be trying so hard to be portable that it ended up being barely
> usable.

I think portability is an important goal and IMO libtool does a
remarkable job simplifying the tedious task of building libraries on
different platforms.  If you can give a short summary why using it was a
"huge mess" in your project I would be very interested.  I'd really like
to understand what the common problems with libtool are.

cheers
sascha

[0] The most famous discussion on this topic is the "debian against libtool"
    case, which was about the unconditional use of rpath by libtool.  In
    the end it turned out, that the whole fuzz was really caused neither
    by libtool nor by rpath in general but by an insufficient
    compatibility hack in the run time linker on the transition from
    libc5 to libc6:
    http://lists.debian.org/debian-devel/1999/01/msg02570.html
--
Sascha Wilde
We're Germans and we use Unix. That's a combination of two
demographic groups known to have no sense of humour whatsoever.
  -- Hanno Mueller in de.comp.os.unix.programming

[Eric M. Ludlam]

On Fri, 2009-10-30 at 14:53 -0400, Stefan Monnier wrote:

> > It would be best to use libtool for linking programs, too -- at least
> > when they are linked against shared libraries which are part of the
> > project.  But this also makes only sense with an install target.
>
> I do not have a strong opinion on this, but IIUC while autoconf seems to
> be usually appreciated, and mostly so as well for automake (tho to
> a lesser extent), libtool has many more detractors because it is a lot
> more invasive.
>
> So it might be good to support projects using libtool, but I think it
> is important not to impose it.

EDE has several kinds of projects it knows how to deal with.  As one
piece in the whole, its job is to help other tools find source code, and
to define boundaries between sourcecode.  ie, some file belongs to this
program, and not that library.

As a user interface, EDE is supposed to make life easier, regardless of
the skills of the person using it.  That's why it can detect and use
pre-written projects.  It knows about Emacs, and Linux Kernels, and it
lets you create a simple configuration that just defines the boundaries
of a project, and it is up the the user to create the makefiles.

It can also detect pre-written automake files, and will just edit them a
little as you go.

With that background, I think that for the project variant that will
create all your makefiles for you, it can follow a similar rule.  It
just needs to make life easier, even for someone who knows a lot about
build systems.

If someone just wants to compile a quick program with 2-3 files (Maybe
more), then they would choose the Make project type, and be good to go
on their Linux system.  If they want something really complex with
shared libraries, and all the other features of Automake, well they
ought to use Automake.

If it is straight forward to get the Make variant to create shared
libraries, that's great, but I don't think EDE should be able to
replicate the power of Automake.  EDE should just have some simple rules
for common cases that it can get right.  I doubt someone who wants to
create shared libraries and the like would base it on EDE, even if it
worked great.  It seems more likely they would use automake, or write it
themselves.

EDE should probably complain if you try to create targets of a type that
EDE doesn't support in the Make variant, and offer to switch to Automake
for you.

I think that the fact that CEDET uses EDE to create all it's Makefiles
is a fine test case that has kept EDE working well, but I don't think
that would be the norm.

To reiterate, if EDE can created shared libraries using the simple
structures it already has, that's great, but if it doesn't really fit,
then EDE should suggest that the user switch to automake.

Eric