Martin
What you are doing is very similar to what I have done in my arduino
eclipse plugin. The names are different but basically I switch
between sam/avr (toolchain) on the fly by selecting different
hardware in a custom made project properties dialog.
I considered/tried the configuration approach as you mention. The
current implementation supports it inside the boards.txt file (Which
is arduino specific but probably comparable to CMake configuration
data).
I find it confusing and hard to maintain because I only want to
change the hardware and keep all of the other options the same
between hardware. Verifying whether all build options are the same
is more work than just modifying the selected board.
In short: in my experience multiple configurations does not really
work out nice to solve this problem.
For the shared code I use linking. That works really great needs no
real additional code and supports having all your code in 1 version
control repository.
I do that as follows: I create 1 project that contains all shared
code each in a separate folder. Each project using shared code links
to the folder(s) in his own project. Version control is configured
to capture changes over the 2 projects.
Just my 2 cent
Best regards
Jantje
Hi Doug,
I'm working on a CMake plugin
targetting
to resolve https://bugs.eclipse.org/bugs/show_bug.cgi?id=350206
so my view is somehow CMake-centric, but must of the following
applies
to qmake and automake, too.
For the New Project Wizard, I
experienced
many of my coworkers to get confused by project types. They may
not choose
"shared library" if they want to build a shared library with
CMake or Autotools. For us a way to distinguish project types
would be
something like: will eclipse take care of the project structure
(compiler
settings, etc.) for me or will I have to do it myself? I think,
that this
is often referred to as "Managed Make" <-> "Makefile
project". But I think it is a little misleading: Build systems
like
CMake would be "Managed Make", but I have to write the project
description (CMakeLists.txt) manually and Eclipse will not know
much about
the project's structure then. Also for project types like CMake
where an
external tool takes care of the compiler settings, property
pages like
C/C++ Build->Settings could be hidden.
At Rohde & Schwarz, we
develop embedded
systems (used in measurment instruments) using different target
architectures
(x86, ppc, ARM). Most of our source code projects are shared
among different
instruments and therefore across target architectures. I spent
quite some
time thinking about if this is an unusual requirement, but even
simple
client-server applications often share some code, a library
implementing
the communication protocol for example. When client and server
run on different
target architectures, then a change in the shared code
(communication library)
needs to be rebuild for both architecures while the
communication library
is still only one source code project in CDT, source control,
etc. A second
usecase for changing the target architecture during work is to
develop
something on the host until it works there and deploy it on the
target
for test then (CDT on Desktop Linux developing for embedded
Linux). This
can save many deployment cycles.
That said, I think it should be
quick
and easy to change the target architecture (toolchain) for a
given CDT
project, just like changing the configuration now. In this case,
it does
not make sense to choose a target architecure/toolchain at
project creation,
the toolchain is defined by CMake, qmake or autotools. The
project itself
(I mean the project description: list of source files, headers,
include
search path, output artefact, ... ) should be
architecture-agnostic.
CMake supports this well by
seperating
the project descripting in CMakeLists.txt and the cross
toolchain definition
in a toolchain file (-DCMAKE_TOOLCHAIN_FILE=file). It's
out-of-source build
makes it easy to generate a ARM Makefile in one folder and a x86
Makefile
in a other folder. Qmake calles this "shadow build" and most
autotools projects can be built out-of-source, too. As changing
the target
architecture for a given project would cause the project to be
build with
a different toolchain in a different folder, it might be
neccessary to
change error parsers.
An easy way would be to use CDT's
configurations
for architectures instead of Debug and Release (yes, thats not
on the first
page any more). That would enable the indexer to have an own
index
for each toolchain as their headers might differ. I even think
about generating
configurations programmatically by combining debug and release
with each
archtitecture, but I will end up with about 10 configurations
then, the
indexer running for each of them...
I try to integrate the "change
target architecture on the fly" feature into the CMake plugin,
let's
see if I get stuck somewhere.
Martin
Von:
Doug Schaefer
<dschaefer@xxxxxxx>
An:
"cdt-dev@xxxxxxxxxxx"
<cdt-dev@xxxxxxxxxxx>,
Datum:
2014-04-22 21:16
Betreff:
[cdt-dev] UX
Discussion - New Project Wizard
Gesendet von:
cdt-dev-bounces@xxxxxxxxxxx
Hey gang,
Even though we're a community spread
across
the globe, it's important that we have real design discussions
and help
plan out our future directions. We can start here on the mailing
list,
and as part of this discussion, we can move it to a different
venue if
it becomes too noisy or too awkward to make our points. As you
can tell
from my blog, http://cdtdoug.ca,
I love to write, so this works best for me, but I moved to QNX
to work
with a team that sits within spitting distance of each other
because I
love that interaction too, well, except for the spitting.
I'd like to do something with the New
Project
wizard. I've wanted to do that for a long time. And now that
we've gone
through the exercise in Momentics, I think we can bring some of
that experience
to the CDT and the Eclipse C/C++ IDE in particular, and anyone
else who
wants to contribute ideas and/or code to reuse it themselves.
But I'm not
sure I have the full perspective on everything all CDT projects
would need.
First up, the biggest problem is the
first
page, and the Project Type and Toolchains panes in particular.
What is
a project type. Is it the type of binary output, executable or
library?
Is it the build system, autotools or qmake or cmake? Is it the
kind of
application, command-line or GUI or plug-in. The target
platform, BlackBerry
or Desktop or Server?
Or do you pick the toolchain you want
first
and then the project type? The UI was mainly designed by a
contributing
company that offered an alternative compiler to gcc so the
choice was left
second which made sense in those scenarios. But how does GCC
cross fit
into that. For many of us, toolchain implies target platform,
but wouldn't
you select the target platform before picking the project type
and then
selecting a toolchain? Are we missing something there?
Right now we have quite a mix of
concepts
being presented in these two panes, project type and toolchain
and the
cohesion is terrible. I'd love to hear what you all think of the
dialog
and how you think it should be changed to make more sense to our
users.
Thanks!
Doug._______________________________________________
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
|
