Re: [cdt-dev] RIP Wascana, Build System discussion

[Doug Schaefer <cdtdoug@xxxxxxxxx>]

Thanks, Leo. I was really testing the waters to ensure that MBS was still a desired component and that people were willing to invest in it. And I see that there is.

I will instead focus on how to improve the Makefile side or standard build if you will. It is a huge high runner test case to allow the CDT to work with projects that also have command-line build facilities. And we haven't touch standard make for many years. And since this is an area I'll be spending a lot of time, I'd like to make the CDT work better there. And who knows, maybe I'll make it so good, it'll look like managed build anyway ;).

Cheers,
Doug.

On Thu, May 21, 2009 at 12:21 PM, Treggiari, Leo <leo.treggiari@xxxxxxxxx> wrote:

FYI;  Intel uses the MBS in its support of the Intel compiler on Linux.  It has always worked quite well for our needs.  We use the standard CDT code and use the makefile generation capabilities.  

 

I don’t think that Windows support is the only reason for MBS.  CDT on Windows was always going to be a difficult sell given Visual Studio’s dominance – and it’s not just their IDE support.  It’s also their compiler and all of the Windows specific technologies that Visual C++ supports.  If you want to use their compiler and libraries, why would you use another IDE?

 

Back to MBS, the idea of not having to manually create makefiles for your project remains very valuable as far as I’m concerned.  Also the idea of being able to integrate a different compiler and fairly quickly provide a usable integration is very valuable.  

 

Thanks,

Leo

 

---

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Thursday, May 21, 2009 8:32 AM

To: CDT General developers list.

Subject: Re: [cdt-dev] RIP Wascana, Build System discussion

 

Agreed. I like how this conversation went and it helped me understand what I need to do. Thanks!

BTW, to show where i'm coming from, the following tutorial made me cringe. This is for using CDT with Moblin. It shouldn't take this many steps to get a Moblin project going. Creating a general project, import a skeleton, then converting it to a CDT project, yikes! This is the kind of workflow I'd like to improve with a good template engine and a little automated makefile management.

http://moblin.org/documentation/moblin-sdk/coding-tutorials/getting-started-developing-eclipse

Cheers,
Doug.

On Thu, May 21, 2009 at 11:23 AM, Chris Recoskie <recoskie@xxxxxxxxxx> wrote:

I agree that investing in the non-managed build is a good thing. I think there are more users there (for us as well), and that stuff has been languishing for a while. I just don't think we can drop MBS either.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

Doug Schaefer <cdtdoug@xxxxxxxxx>

Doug Schaefer <cdtdoug@xxxxxxxxx>

Sent by: cdt-dev-bounces@xxxxxxxxxxx

05/21/2009 11:16 AM

Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

To	"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
Subject	Re: [cdt-dev] RIP Wascana, Build System discussion

 

Maybe there's ways to do both. Maybe what I'm thinking about is improving Makefile projects to take into account the build definitions and the list of resources. That could be done in parallel with whatever effort goes into the managed build project types.

Doug.

On Thu, May 21, 2009 at 11:02 AM, Chris Recoskie <recoskie@xxxxxxxxxx> wrote:

I think your statement that there is little commercial interest in managed build is wrong. IBM is going to be shipping products that use it, which means I am spending more time on it now than I was before. I know from my time at TI that it was heavily used there. QNX uses it, don't they? I'm sure there are others.

I think there is a lot of interest in the idea of MBS. I think the problem is that the design and implementation were half-baked in a lot of places, and revolved so heavily around the GNU tools that it's hard to get it to work for anything else. For some this means they had to roll their own. For others it means they hack up what's there as best as they can and limp along.

I'm not planning to drop MBS any time soon. Gut it? Maybe. If anything I'd like to eventually drop makefile generation as a feature, but last time I suggested that, there was practically a riot.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto
cdtdoug@xxxxxxxxx

 

cdtdoug@xxxxxxxxx
Sent by: cdt-dev-bounces@xxxxxxxxxxx

05/21/2009 10:45 AM

 

Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

To	"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
Subject	[cdt-dev] RIP Wascana, Build System discussion

 

I'm abandoning Wascana, at least for now. If you haven't seen my blog entry, please take a look: http://cdtdoug.blogspot.com/2009/05/wascana-is-over.html
. I have little time to spend on CDT and I'd prefer spending it on the infrastructure to support things I actually work on. I don't spend much time in Windows any more. As I said in the blog entry, if anyone wants to carry the torch for CDT on Windows, I'd be happy to provide guidance.


That brings up something radical that crossed my mind. I started this whole build model thing for two reasons. One, to allow us to create modeling tools that work with build settings (big business there ;) and to equal Visual Studio's managed build system, which as I abandon Wascana, doesn't matter as much to me anymore. It really looks like we don't have enough investment to keep the build model going and to fix all of the issues with it. I'm wondering if a new approach is required.

Alain's work on the Makefile editor to provide a good parser for it opens some doors. And given the power of gnu make, I wonder if building a strategy around a good makefile editor, a la the plugin.xml or Android manifext.xml editors, and a good template engine to create Makefiles with enough information to build certain types of projects, would be a more practical approach. Gnu make is available on our three major platforms, Windows, Linux, Mac, but we need to confirm availability for other platforms. Also the vast majority of our users use gcc, and we could continue to rely on gcc generated dependencies and abandon the internal builder entirely. The build definitions can still be used to provide info to customize the Makefile editor and to provide scanner Info.

This is something that just jumped into my head in the last couple of days and needs to be fleshed out. It still needs a story for people using non-gnu tooling. And there are some good things in the current system we should keep, like the scanner provider stuff (but in a simpler way), resource specific build info, build exclusions, configs, flexible UI.

But at this stage of the game, I think it's important that we pick a solution that is practical given that we have such little commercial interest in CDT's managed build solution. Everyone still has their own build system, so why are we investing in something big that most CDT users don't need.

Please let me know what you are thinking and we can discuss further in upcoming conference calls. I'll continue to flesh out this story so we can make an decision on it. Unless you all think it's crap in which case, I can drop it.

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

_______________________________________________
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

 

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev