Mail Archives: djgpp/1997/10/15/14:22:48
Peter Palotas <blizzar AT hem1 DOT passagen DOT se> wrote:
> At 16.51 1997-10-14 +0000, you wrote:
> >Peter Palotas <blizzar AT hem1 DOT passagen DOT se> wrote:
> >> At 15.24 1997-10-14 +0000, you wrote:
> >> >Peter Palotas <blizzar AT hem1 DOT passagen DOT se> wrote:
> >> >
> >> >> Is there any way to tell the RHIDE in what order to compile the project
> >> >> files. It seems to be sorting them by their name right now, but this
> might
> >> >> not always be what you want. (Ofcourse you could change the name of the
> >> >> file too, but this isn't a good solution according to me). If there
> isn't a
> >> >> way to do this, what about implementing it!?
> >> >
> >> >This was discussed some time ago and nobody was able to show an example
> (of
> >> >logic code ;-) that really needs a sequence of compilation/link.
> >> >Why do you want to tell an specific order? I only make a similar thing
> >> when I
> >> >want to test the compilation of one file without compiling the rest first,
> >> for
> >> >this there are an option to compile one file.
> >>
> >> Well, I think I can give an example. I want to compile a file which outputs
> >> a headerfile (.h). And this file is included in some of the .C* files that
> >> I compile. (Compile might be the wrong work, but anyway... I use some AWK
> >> scripts/programs and CPP to generate a headerfile from several others
> >> anyway, and this has to be created *before* any of the other files are
> >> compiled).
> >
> >That's a very different thing until now I don't know any way to make that.
> >That's one of the big problems with bison, flex and gperf all of this
> generates
> >C files and they aren't supported.
>
> Now that you mention this, I recall having this problem earlier too when
> using Bison. So I don't quite understand what you meant when you said that
> "noone could come up with a situation when this was neccessary!
Because that's a different situation, you asked about changing the project
order and not about having double dependencies in the project. These things are
totally different.
> >There are a way to force the order:
> >1) Enable the option to add the directories in the project.
> >2) Put the files that generates the .C files in a subdirectory called "A" or
> >similar.
> >3) Move the files there and adjust your tricks to generate the files over
> the
> >main directory of your project or other called B for example.
> >
> >RHIDE will order alphabetically but the subdirs will act as a prefix forcing
> >the sort ;-)
>
> Well, yes, this is a method, although not a good one. (In my oppinion no
> better than renaming the file itself).
A question of taste.
> Why should RHIDE sort the files anyway?
I find it a lot useful because I make searchs in the project typing the first
letters of the name. Alt-0 doesn't help when the project is huge and splitted
in various directories.
> I see no point whatsoever in *that*!
I use it ALL the time.
> Why not just add an option *not* to sort the files,
Robert must ask it , but is a little complex because ones the files are sorted
you can revert it, it must be done before. But he must say if he wants to add
it or not.
> and being able to move them around in the project
> window so that you could specify in what order to compile them!?
Because there is no reason to do that, what you want must be done in other way.
In my opinion the best thing is support some kind of cross-dependencies, that's
dependencies between project items, but again the last word is the Robert's
one.
> I think this is a very good idea, and I'm sure that lots of people agree,
> since it would really make life easier when using bison, and other programs
> that generate .C files (or .H files for that matter).
Not really true, sometimes the dependencies can't be expressed just by the
order in a list. In fact the dependencies are like a tree.
SET
------------------------------------ 0 --------------------------------
Visit my home page: http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-sot AT usa DOT net - ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
- Raw text -