[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU make integration through an IDE
From: |
Noel Yap |
Subject: |
Re: GNU make integration through an IDE |
Date: |
Fri, 03 Oct 2003 09:08:00 -0400 |
"Paul D. Smith" wrote:
> Yes, not only in theory but in fact.
>
> But what I'm saying is that if you're providing a capability to jump to
> where a target is defined, you'll have to pick one of those. How do you
> choose which one? Or do you list the install target 3 times?
Not that I agree with creating an IDE, but how do IDE's typically do it for
overloaded function names and re-used static linkage or anonymous namespace
symbols?
> Hm. OK, well, maybe I don't understand what you're looking for then.
> Note that of the 5 directories the first one might have 3 files that
> could be built, the second one 3,000, the third 50, etc. so any progress
> meter that simply relied on those 5 directories without knowing what's
> in them wouldn't be very accurate.
IMHO, this is another reason not to use recursive make.
> Ah! So, it's very like VC++ project files or something.
>
> Well, that's one way to do it, and if you do this then certainly most of
> the advanced features we've been discussing are things you won't have to
> worry about: since you're writing the makefile it's doubtful you'd
> include those things (they are hard to automate).
OTOH, developers who know make and want to take advantage of advanced features
will be extremely limited and frustrated. I know I would be.
For example, as I've said before, we have a standard infrastructure. But being
an infrastructure, I'm free to use the parts I want, override the parts that
don't fit, and add stuff I want. In my specific case, I was able to encode our
package version
dependencies and have them checked at build time (ie during make makefile
parsing) such that conflicting versions will cause a build error.
> As a _user_ I know what I would want though: I would want two modes.
> One that wrote makefiles for me using whatever method you come up with:
> directly, through automake, whatever. As long as it was drop-dead
> simple to use and accurate; in this mode I'd probably never care to even
> see the makefile.
I just use "cp" on an existing makefile :-)
> The other mode would be a "passthrough" mode which let me write my own
> set of makefiles; here I'd want as much of the "helper" infrastructure
> as practical including the editor help, the markup of make output to
> find errors, etc. etc. BUT! in no way should that mode constrain what I
> put into my makefile. In that mode every decision of the IDE should be
> "lenient"; it should not force me to do anything. If the IDE doesn't
> recognize what I'm doing it should shrug and just do its best to
> interpret it, but let me do it.
I completely agree.
MTC,
Noel
--
NOTICE: If received in error, please destroy and notify sender. Sender does
not waive confidentiality or privilege, and use is prohibited.
- Re: GNU make integration through an IDE, (continued)
- Re: GNU make integration through an IDE, Paul D. Smith, 2003/10/01
- Re: GNU make integration through an IDE, Alain Magloire, 2003/10/02
- Message not available
- Re: GNU make integration through an IDE, Paul D. Smith, 2003/10/02
- Re: GNU make integration through an IDE, Alain Magloire, 2003/10/02
- Re: GNU make integration through an IDE, Alain Magloire, 2003/10/02
- Re: GNU make integration through an IDE, Noel Yap, 2003/10/02
- Re: GNU make integration through an IDE, Alain Magloire, 2003/10/02
- Message not available
- Re: GNU make integration through an IDE, Paul D. Smith, 2003/10/02
- Re: GNU make integration through an IDE, Alain Magloire, 2003/10/02
- Message not available
- Re: GNU make integration through an IDE, Paul D. Smith, 2003/10/03
- Re: GNU make integration through an IDE,
Noel Yap <=
- Re: GNU make integration through an IDE, Alain Magloire, 2003/10/03