|
Possibly, though the install target is very abstract, and actually even a violation of Make as most .PHONY targets are.
I guess what’s really coming about as I map the workflow out is that Launch drives Build. That’s the real paradigm shift here. You build something because you want to run it. You need to understand how (mode) and where (target) you want to run it before
you can decide how you want to build it.
I’ve always felt that launch and build needed to be tied together and now I’m starting to understand why I felt that way. Until now, for whatever reason, we’ve treated them as independent components. But when you tie them together, it makes for a really
nice user experience.
Now I know there are users out there that only build or only debug using CDT and they should continue to be supported. But I want to make this really good for those who use the IDE to it’s fullest capability.
Doug.
Regrading searching the project for the binaries that are relevant for the launch:
There is a mechanism often found in Unix Makefile: the install target. CMake, qmake and autotools support them, too. Although we can not rely on a proper install target for every project, it is very handy to seperate the real
build output from intermediate files if there is one. So we still need a plan B for those projects that don't implement a proper make install target in their build system.
In short:
"make install" copies all files needed to their destination locations. The environment variable DESTDIR adds a path suffix to the installation paths.
If CDT would call "make install DESTDIR=/some/empty/dir" after the build, all binaries, libs, config files etc will appear there and CDT can just collect them to know what to transfer to the target.
Most open source projects keep their build system's make install targets in shape, because this mechanism is also used by the Linux distributions to know which files to package into .deb or .rpm.
Martin
Von: Doug Schaefer <dschaefer@xxxxxxx>
An: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Kopie: "cdt-dev-bounces@xxxxxxxxxxx" <cdt-dev-bounces@xxxxxxxxxxx>
Datum: 2015-09-22 16:58
Betreff: Re: [cdt-dev] Antwort: Thoughts on Launch
Gesendet von: cdt-dev-bounces@xxxxxxxxxxx
That’s a great point and one of the cool things about CMake. I’d consider this all one project, not separate projects. And, yes, it builds multiple executables per project. And that’s why I’m careful to mention that the one
binary per project idea only works with certain project types. It doesn’t work with CMake.
At the same time, with CMake, we should be able to find all the executables by looking at the CMakeLists.txt file set. We could then present the executables as the launch descriptors so you can select which one to launch. And
if we structure the build output directories properly, we should be able to find the binaries for those executables for the different build configurations.
So in that sense, we’re still not one binary per launch config. It’s some higher level concept (I’ve carefully called ‘executable' above) that programatically maps to different real binaries depending on mode and target.
The key is to be flexible and that likely means different launch configuration types for the different systems. Which interestingly enough is what vendors do anyway. Few vendors that build their toolchain integrations on top
of CDT use CDT’s launch configuration types, or project types for that matter.
I think that’s probably the fundamental paradigm shift here. Having one set of launch configurations for all CDT workflows doesn’t make sense and really never did. And funny enough, most of that knew that already but let it
go. It’s time to fix that.
Doug.
From: <cdt-dev-bounces@xxxxxxxxxxx> on behalf of "Martin.Runge@xxxxxxxxxxxxxxxxx"
<Martin.Runge@xxxxxxxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Tuesday, September 22, 2015 at 10:31 AM
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Cc: "cdt-dev-bounces@xxxxxxxxxxx" <cdt-dev-bounces@xxxxxxxxxxx>
Subject: [cdt-dev] Antwort: Thoughts on Launch
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
_______________________________________________
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
|
