From: "Eric M. Ludlam" <eric@siege-engine.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Sascha Wilde <wilde@sha-bang.de>, emacs-devel@gnu.org
Subject: Re: EDE: make project shared objects
Date: Sat, 31 Oct 2009 08:14:00 -0400 [thread overview]
Message-ID: <1256991240.5333.292.camel@projectile.siege-engine.com> (raw)
In-Reply-To: <jwvaaz8af7u.fsf-monnier+emacs@gnu.org>
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
prev parent reply other threads:[~2009-10-31 12:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1256991240.5333.292.camel@projectile.siege-engine.com \
--to=eric@siege-engine.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=wilde@sha-bang.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.