Hi Doug,
I appreciate this initiative. I will make some comments here but
if you prefer them registered on the wiki/bugzilla too, please let
me know.
First of all, I'd like to give a simplified description of my [1]
users and scenarios:
- they are mostly ISVs porting and/or tuning C/C++ apps to IBM
POWER processors. Almost always an already existing code should be
imported into Eclipse, and built with make (it can be "pure" make
or autotools managed). Some use custom scripts and I've seen
interested growth on use of CMake too.
- they build it locally using a cross compiler or direct on the
remote target machine (preferred method).
- it is provided a self-contained version of GNU toolchain [2]
and runtime libraries optimized for our platform that does not
overridden the default Linux distribution toolchain/libraries.
E.g., gcc can be installed under /opt/at8.0/bin/gcc and
/opt/at9.0/bin/gcc. Our users want to use that toolchain instead
of the distro's provided one.
- we provide a plug-in called Build Advisor that parses the build
output, analyses flags/commands issued and makes recommendations.
According to the scenario outline, below are some of our needs
for the new build system:
- It could be more remote-aware, allowing build commands and
scanner info be execute on any target build machine. The CDT's
autotools plug-in already provides remote facilities, whereas make
target doesn't. Today we rely on PTP's extensions for CDT and
synchronized projects.
- It could implement an "build environment configuration"
facility similar to PTP's environment modules [3] and Environment
modules [4] so that any toolchain integrator could provides
pre-defined environment configurations (i.e. variables to be set
before the build). It has potential to solve problems related with
known toolchains installed on different locations, besides
allowing users to more easily switch between cross compile
configurations.
- the output parser could be a general purpose API, i.e., not
necessarily attached to any toolchain. Today, If I understood
correctly, it is tied with a toolchain and should be used solely
to parse build errors and feed the scanner info.
References
[1] IBM SDK for Linux on POWER - https://ibm.biz/BdXiAr
[2] IBM Advance Toolchain - https://ibm.biz/BdRCHZ
[3] PTP environment modules - https://ibm.biz/BdrBqm
[4] Environment modules - http://modules.sourceforge.net/
----------------
Well, I think it's all for now :)
Thanks!
Wainer
On 06/28/2016 01:49 PM, Doug Schaefer wrote:
Hey gang,
I’ve started capturing notes on how we could bring Standard
builds to the new build system. Feel free to comment on them, or
ask questions.
The main thrust is to make Make Targets a first class citizen
again (and rename them Build Targets) for Standard builds. Also
to keep ToolChains as first class citizens in the Standard build
system since they make life so much easier with scanner info and
determining launch targets and such.
Thanks!
Doug.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev