[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] CDT 4.0 M6 Countdown
|
Hi Mikhail,
Thanks for your comments.
With toolchain paths, I mean binary, includes, libraries.
For example, I usually do not add the compiler paths to the Windows
environment, as this just gives me a mess, having e.g. Cygwn, MinGW,
VS2005, or e.g. PSDK/DDK, or several kind of embedded compilers. I'm not
even sure, how much the Windows PATH variable can hold. Also make.exe !=
make.exe for every toolchains. They might have the same name, but
different options and implementations.
So, in MBS, I added the path to GCC in the project tool pages.
Henning
Sennikovsky, Mikhail schrieb:
Hi Henning,
Please see my comments embedded below.
Mikhail
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of kesselhaus
Sent: Wednesday, March 28, 2007 4:56 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] CDT 4.0 M6 Countdown
* Something about the project settings pages:
With the new project model, thing got a bit "bloated" there. Could
it be, that there are some kind of duplicate settings?
1.) C/C++ Build Variables, is this something like the symbol
defines in the Compiler settings page of GCC?
*/[Mikhail] The CDT Build variables are actually the same as “Build
Macros” concept that was used in MBS and now migrated to the core. The
main idea of this functionality is to allow defining and using the
so-called “Build Variables”(“Build Macros”) in the string option
settings (e.g. in include paths) in the form like ${macro_name} the
macro gets expanded internally to its value when the option is used./*
*/ /*
2.) C/C++ Export Settings, see 1.),
*/[Mikhail] The idea of the “export settings” mechanism is to allow
one project to export some of its settings and to allow those settings
to be used by other projects referencing that project, e.g. in case
the project builds the library, it can export its library and include
path for the library being built. In this case when some other
projects refer library project, their library and include path
settings get automatically adjusted./*
*/I agree that the name of this property page might be confusing,
especially since the page contents seems similar to the contents of
the “C/C++ paths and symbols”. Also this functionality was not
debugged properly./*
*/I think we can remove disable the “Export ”property page for the M6
and re-think its name and look-and feel to avoid further confusion./*
3.) C/C++ Project paths and symbols, see 1.) and whats the
difference to settings 2.)
*/[Mikhail] This page is used to provide include/library/symbol path
to the Core and Build System./*
If they are duplicates of C/C++ Build Settings for GCC, are they
merged together.
I'm a little bit confused currently on how to try this stuff out.
Its like, where the heck do I add my include paths and
library/libpaths, e.g. pthreads, or some other lib from another project.
How to do this for Unixoid and how for Windows system?
*/[Mikhail] You should use the “C/C++ paths and symbols” page for
that. In case of using the “Managed Build” mode (i.e. makefiles are
generated automatically or the Internal Builder is used), you can as
well set those settings in the “Tool Settings” tab of the “C/C++ Build
settings” property page (as was in CDT MBS 3.x) the settings of that
tab will be consistent with those displayed in the “C/C++ paths and
symbols” page./*
Where to select the builder (Internal vs make vs mingw32-make),
*/[Mikhail] the builder settings are available in the “Builder
settings” tab of the “C/C++ Build settings” property page/*
where to add toolchain paths, is this per PATH or do I add this in GCC
settings for each tool?
*/[Mikhail] Could you elaborate a bit more on this question? What kind
of “tool-chain paths” to you need to add?/*
*/Regards,/*
*/Mikhail/*
Regards,
Henning
Doug Schaefer schrieb:
>
> Hey gang, good progress today. My sanity now passes (now using MinGW,
> woo hoo!). We still have a few bugs to clean up, though.
>
>
>
> 22 bugs found.
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
------------------------------------------------------------------------
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
