>
First, thanks for taking the time to respond some of the inquiries.
> >> where do you go when the user asks to go to "install"?
>
> am> Ho! I do not know. But it should not matter, we parse the
> am> makefile and provide the users with a list of the targets. In
> am> your example sh
"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 wit
%% "Alain Magloire" <[EMAIL PROTECTED]> writes:
>> where do you go when the user asks to go to "install"?
am> Ho! I do not know. But it should not matter, we parse the
am> makefile and provide the users with a list of the targets. In
am> your example should not the "install" targets be
>
> am> It looks like a Class View, the widget is a tree, that shows the
> am> directives of the makefile, it turns out to be practical, for
> am> makefile browsing etc .. select a node it position the editor
> am> cursor at the right place, future could do some quick action, like
> am>
>
> Alain Magloire wrote:
> > I am just looking for feedbacks on how to tackle the issue, maybe the answer
> > is not to change make and build other tools around it that can exploit its
> > build paradigm?
> > The goals are simple, help the users in the development cycle.
>
> We have a standard,
Alain Magloire wrote:
> I am just looking for feedbacks on how to tackle the issue, maybe the answer
> is not to change make and build other tools around it that can exploit its
> build paradigm?
> The goals are simple, help the users in the development cycle.
We have a standard, well-documented m
%% "Alain Magloire" <[EMAIL PROTECTED]> writes:
am> It looks like a Class View, the widget is a tree, that shows the
am> directives of the makefile, it turns out to be practical, for
am> makefile browsing etc .. select a node it position the editor
am> cursor at the right place, future co
>
> am> Let's start with a few:
>
> am> 1) Error Parsing.
>
> What about it?
>
> am> 2) Makefile editing/parsing.
>
> Why is editing makefiles something that GNU make needs to handle? There
> are things like Emacs makefile mode, for example, that already do a very
> nice job of this.
>
Bonjour
> am> (1) && (2)
> am> I've dealt with those a little differently: by providing in the
> am> IDE a Makefile Editor that understands GNU peculiar(really
> am> peculiar/inconsistent 8-) syntax, it provides:
>
> There's nothing about GNU make syntax that's more peculiar or
> inconsi
%% "Alain Magloire" <[EMAIL PROTECTED]> writes:
am> Let's start with a few:
am> 1) Error Parsing.
What about it?
am> 2) Makefile editing/parsing.
Why is editing makefiles something that GNU make needs to handle? There
are things like Emacs makefile mode, for example, that already do a v
> am> For example to do a real Progress monitor, meaning how to provide
> am> feedback to the users on how many commands done so far and how
> am> many left ?
>
> First, make can't tell you how many commands are left because it doesn't
> know. This came up a few weeks ago. The way make wor
%% "Alain Magloire" <[EMAIL PROTECTED]> writes:
am> For example to do a real Progress monitor, meaning how to provide
am> feedback to the users on how many commands done so far and how
am> many left ?
First, make can't tell you how many commands are left because it doesn't
know. This came
Bonjour
Integrating make as the underlying engine ... is not easy 8-)
For example to do a real Progress monitor, meaning
how to provide feedback to the users on how many commands done so far and how many
left ?
How to extract information from make, i.e. make has all sort of information
13 matches
Mail list logo
