Oscar Fuentes wrote:
>Just chiming in without reading the whole message, much less the whole
>>>So...your IDE generates a makefile to build the user's
>>>application? I used to know something about borland's
>>>C++ IDEs, and IIRC they originally had the IDE program
>>>take care of invoking the compiler and linker, but later
>>>used makefiles for everything. So it sounds like you're
>>>already taking advantage of what they learned.
>For recent Borland C++ products (i.e. C++ Builder) the IDE has a
>project file which is *not* a makefile. The IDE builds the project
>without using 'make'.
Same for M$VC.
>IMHO, for a specialized IDE (that is, one that focus on a restricted
>set of languages) an internal build mechanism is more convenient if
>you want to provide a wide array of features. GNU Make (and other
>make's, BTW) are general-purpose build systems which carries their
>philosophies with them. You just found something you want and that is
>not easy to do with GNU Make.
Precisely, I found a problem with gcc's preprocessor. Only gcc3
provides the feature I expect.
>An internal build system gives you
>freedom for doing whatever you want.
I doubt that I could write an internal build system as powerful as make.
OTOH, with my app the user can click "Project/Create Archive"
and provide the zip to anyone having MSYS, just telling:
Extract the sources, cd to "src" and type "make CFG=Release".
Without even having the IDE installed. :)
This should work as well under Linux, if the project have a WineLib
config, the user would type "make CFG=WineLib".
WineLib is designed to build Windows sources under Linux, BTW.
(My IDE was built and run under WineLib :)
Unfortunately, gcc3 will be required, it's not a problem for me, but
I'm quite sure that someone may want to use an older gcc.
That would output warnings about unsupported switches and
worse, even if it builds, dependencies may be broken.
Dependencies should then be generated with a dedicated
generator or using sed.
Here is the problem, to guess the compiler version, to do things
>In case you insist on delegating the build process, have you seen
>Boost Jam? It is an enhanced version of Perforce's Jam. It is not
>restricted to C++. IMO, it is not so easy to master as GNU's make for
>simple projects, but way more powerful, mostly because you can provide
>"variations" on independent files which divides the build process on
>orthogonal sets of "how-to" information (tool options, target types,
>file locations, etc):
Haha, I'll study it. Thanks.
>Another possibility is to embed an scripting language like Python and
>to emit Python code for building your projects. The user can provide
>code snippets for overriding default behaviors or for extending the
I see, that's a possibility, yes.