Re: [Dev-C++] can't get dev-cpp to compile...
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
Re: [Dev-C++] can't get dev-cpp to compile...
|
From: RUDOLPH B. <ku...@sp...> - 2004-01-19 00:15:43
|
BRAVO BRAVO
WELL WRITTEN
----- Original Message -----
From: "* William" <wi...@fu...>
To: "dev c++" <dev...@li...>
Sent: Saturday, January 17, 2004 7:41 PM
Subject: Re: [Dev-C++] can't get dev-cpp to compile...
Hello 'world' ...
Comments below ..
----- Original Message -----
From: OROSZI Bal=E1zs
Sent: Sunday, January 18, 2004 5:13 AM
Kovalan Muniandy wrote:
K>> ... The code was generated by Dev-C++ (The project wizard "Hello
World"). I
K>> guess that's a bug.
B> Only applies to C++ headers - it is a standard. The C standard library
B> BTW, it indeed is a bug. Dev-C++ has quite old project templates. And
B> that would the smaller problem, but there are bigger ones. The usage o=
f
B> MinGW (the compiler beneath Dev-C++) is still used in a very obsolete
Yes, and at the same time, I think it is unfair to 'expect' on the Dev-CP=
P
team to keep abrest of every subtle change or update in the compilers. C
and C++ is a tool for people who will one day 'know' what their code does
and does not do (I am allowing for learners too, you see... *smile*).
I also thing there is something that can be DONE to redress the catch-up
process between Dev-CPP and an innovation in the compiler, or verily, any
other 'tool' or library.
Some of this I've discovered it is possible to do by hand, and yes it is
related to the templates (.devpacks), which means ALL of us can develop
better "Dev-CPP structures" and directory hierachies, to support changed =
in
the underlying tools. (Me too ...oops).
The compiler is a brilliant example. The 4.9.8.5 Dev-CPP uses
gcc.exe (GCC) 3.2 (mingw special 20020817-1)
compiler. It is installed 'under' the Dev-cpp folder hierachy. As
(visual)
./dev-cpp/bin/gcc.exe
/include
/lib
While this all makes sense if one is using only one compiler, and
environment say as I might with a microsoft(r) product. Does it make sen=
se
in the Dev-cpp world. I recently grabbed the mingw 3.3 compiler suite.
gcc.exe (GCC) 3.3.1 (mingw special 20030804-1)
And I placed it as a seperate hierachy so I can have different versions o=
f
the same tool placed so I can use the compiler of choice. For example;
./dev-cpp/bin (same, left it alo=
ne)
./mingw32/3.2/bin/gcc.exe
/include
/lib
./mingw32/3.3/bin/gcc.exe
/include
/lib
./wxWindows/ ......
Please note, my example of wxWindows... I can't "enforce" this on people,=
it
is simply something I think will work better for me. I have found occasi=
ons
when moving to a new version causes problems. If I can alter the path to
point to a different configuration, and go backwards or forwards that is =
a
good thing.
It is also set up this way because Dev-cpp is not always the only tool to
use these directories and I don't want to point makefiles into a 'product
specific' folder layout. In make, I cna use relative path references.
"../../here" and macros "$(WXSTUB)/include"... Hey it gets creative.
The consisitient point is by changing ONE folder (parameter) for a make, =
I
can build with a beta or a stable release, or old release. Because there=
is
a consistiency and anyone can setup their directories this way by hand.
So much the better imho, if the DevPack templates WE makeup started to
'think' like this. And the 'think' is probably why things are as they ar=
e.
At some point there would need to be a 'consistient agreed scheme' so tha=
t
might work.
Something deep and challenging and complex like a "dev-cpp.config" file
perhaps ?
It could look like:
[wxWindows] // peer tool
path: $(package)/wxWindows
[mingw32] // peer tool
path: $(package)/mingw32/$(ver)/
[winmerge] // peer tool
path: $(tool)/winmerge/
[cvs] // peer tool
path: $(tool)/cvs/
Where $ver is the user designation (folder name) or null for that version.
An empty $(ver) might be the default compiler, wxWindows, resource editor=
,
etc
And the macro: "$(package)" is a folder path where these toys 'go to'.
The other thing is sometimes, there are tools already in place, that I ca=
n't
"just move" because that might mean changing other bits and pieces. I'm
pointing out user-supportive concepts. It is rare for most people to hav=
e
to work where I can make No assumptions about the deployed-configuration =
for
software. That is changing. OSS means plug-n-play together. So think
flexible folks...
That's a 15 min write-up. It seems to me that 'chaotic' tool use and
placement forces people into two modes. First is a supportive mode where
everything goes HERE. Second is a spend a few days (hours then) configur=
ing
where things go... do-it-yourself.
A few macros, with default values and using relative paths can offer a
median path between flexibility and utility. To its credit, DevCPP allow=
s
me to set-up my folders how I wish. It is the way DevPacks and tempelate=
s
are organised that stop it being 'as valuable' as it might be. Or to be
fair, it is the way it began and has not been looked at ...
As the 'customers' and 'users' of dev cpp we could begin consensus for
peer/external (to dev cpp) tools and add-ins. It isn't the dev cpp's
business if you need to use mingw v2.x, but if you upgrade dev cpp, it mi=
ght
break your project by up-dating the compier.... oopz.
What I can not find so far is where the Dev CPP defaults are maintained. =
I
would hope they are in some resouce and not compiled Into dev cpp ???
Aloha,
William
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
|
