* EDE: make project shared objects @ 2009-10-29 15:01 Sascha Wilde 2009-10-30 11:36 ` Lluis 2009-10-30 13:06 ` Sascha Wilde 0 siblings, 2 replies; 7+ messages in thread From: Sascha Wilde @ 2009-10-29 15:01 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 508 bytes --] 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... :) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: ede-make-shared.diff --] [-- Type: text/x-patch, Size: 1325 bytes --] 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") [-- Attachment #3: Type: text/plain, Size: 429 bytes --] 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." ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: EDE: make project shared objects 2009-10-29 15:01 EDE: make project shared objects Sascha Wilde @ 2009-10-30 11:36 ` Lluis 2009-10-30 13:06 ` Sascha Wilde 1 sibling, 0 replies; 7+ messages in thread From: Lluis @ 2009-10-30 11:36 UTC (permalink / raw) To: Sascha Wilde; +Cc: emacs-devel [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=utf-8, Size: 928 bytes --] 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: EDE: make project shared objects 2009-10-29 15:01 EDE: make project shared objects Sascha Wilde 2009-10-30 11:36 ` Lluis @ 2009-10-30 13:06 ` Sascha Wilde 2009-10-30 18:53 ` Stefan Monnier 1 sibling, 1 reply; 7+ messages in thread From: Sascha Wilde @ 2009-10-30 13:06 UTC (permalink / raw) To: emacs-devel Sascha Wilde <wilde@sha-bang.de> 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: EDE: make project shared objects 2009-10-30 13:06 ` Sascha Wilde @ 2009-10-30 18:53 ` Stefan Monnier 2009-10-31 5:30 ` Miles Bader 2009-10-31 12:14 ` Eric M. Ludlam 0 siblings, 2 replies; 7+ messages in thread From: Stefan Monnier @ 2009-10-30 18:53 UTC (permalink / raw) To: Sascha Wilde; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: EDE: make project shared objects 2009-10-30 18:53 ` Stefan Monnier @ 2009-10-31 5:30 ` Miles Bader 2009-10-31 12:07 ` Sascha Wilde 2009-10-31 12:14 ` Eric M. Ludlam 1 sibling, 1 reply; 7+ messages in thread From: Miles Bader @ 2009-10-31 5:30 UTC (permalink / raw) To: Stefan Monnier; +Cc: Sascha Wilde, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: EDE: make project shared objects 2009-10-31 5:30 ` Miles Bader @ 2009-10-31 12:07 ` Sascha Wilde 0 siblings, 0 replies; 7+ messages in thread From: Sascha Wilde @ 2009-10-31 12:07 UTC (permalink / raw) To: Miles Bader; +Cc: Stefan Monnier, emacs-devel Miles Bader <miles@gnu.org> wrote: > Stefan Monnier <monnier@iro.umontreal.ca> 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: EDE: make project shared objects 2009-10-30 18:53 ` Stefan Monnier 2009-10-31 5:30 ` Miles Bader @ 2009-10-31 12:14 ` Eric M. Ludlam 1 sibling, 0 replies; 7+ messages in thread From: Eric M. Ludlam @ 2009-10-31 12:14 UTC (permalink / raw) To: Stefan Monnier; +Cc: Sascha Wilde, emacs-devel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-10-31 12:14 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-10-29 15:01 EDE: make project shared objects Sascha Wilde 2009-10-30 11:36 ` Lluis 2009-10-30 13:06 ` Sascha Wilde 2009-10-30 18:53 ` Stefan Monnier 2009-10-31 5:30 ` Miles Bader 2009-10-31 12:07 ` Sascha Wilde 2009-10-31 12:14 ` Eric M. Ludlam
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.