[cdt-dev] Antwort: Thoughts on Launch

[Martin.Runge@xxxxxxxxxxxxxxxxx]

Hi all,

With CMake, it not unusual to have projects
that build multiple executables.
E.g.

project
+- client
| +- client-untittest
+-server
| +- server-untittest
+-commlib 
  +- commlib-untittest  
      # <- even a library project might have an executable
to debug

Two ways are common to handle this with
CMake:
1) One single CMakeLists.txt at project
level 
     with multiple targets
inside and relative paths to the sources of the sub projects
2) A "master" CMakeLists.txt
including the subprojects via sub_directory() 
    Each sub-project has its
own CMakeLists.txt.

In both cases, CMake can hande dependecies
between the subprojects and if for example all thee subprojects use boost,
cmake will only check for boost once. Very nice to build large projects
on the commandline.

In case 2), it is possible to treat
the subprojects as seperate projects in eclipse and tie them together with
project references (you need to take some care that the subproject's CMakeLists.txt
is written in a way that they work stand-alone _and_ as subprojects of
the master-CMakeLists.txt).

So I'm not sure if the assumption of
one binary per project is feasible. At least we need a way to explain to
the user, that if he complies to a certain project structure, he will get
some benefits, and otherwiese hast to setup these parts manually. ( what
project structure? which parts manually?) too confusing?

best regards
Martin





Von:      
 Doug Schaefer <dschaefer@xxxxxxx>
An:      
 CDT General developers
list. <cdt-dev@xxxxxxxxxxx>
Datum:      
 2015-09-21 21:40
Betreff:    
   [cdt-dev] Thoughts
on Launch
Gesendet von:    
   cdt-dev-bounces@xxxxxxxxxxx

---

Hey gang, we’ve talked about this recently
and I’ve finally run into it head on with Qt. And it’s really the launch
bar that ties the entire edit/build/debug cycle into a single workflow
that’s got me here.

CDT launch configurations are really
about launching binaries. You have to specify the binary in the configuration
and you have to have a different configuration for each binary. In the
general case, it’s really hard to find binaries that are related and get
it right 100% of the time without asking the user.

For Qt, as with other project types
we have, the source in a project produces a single executable but with
different build configurations for launch target and launch mode. In theory,
I should be able to figure out where the executable is at launch time,
I.e. In the launch delegate, and not have to store it in the configuration.

Ideally, I have one configuration and
it uses the IRemoteConnection API to start the processes, including on
the Local machine.

For debug, I should be able to find
the debugger based on the toolchain I used for the build. The interface
to start up the debugger, the launch configuration can ask the toolchain
where the debugger is and start it up.

I imagine there is a lot different between
remote and local that may warrant two launch configs. For Remote, you may
want to specify a list of files that you want to download aside from the
obvious executable. For Qt, I’d want to download the Qt libraries I’m
using. I may also want to sync QML and other files that can be reloaded
on the fly.

So maybe there’s two launch configs,
one local and one remote, but only 2. Not one per binary.

I’d love to hear your thoughts on this
problem. My conclusion is that I need to create new launch delegates and
associated launch configurations for Qt. I had to do that with Arduino,
so maybe that’s the natural progression here.

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