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

[Doug Schaefer <cdtdoug@xxxxxxxxx>]

Thanks, James. When I say Makefile editor, I'm not focused on the text editor part. As with the plugin.xml editor, I can envision forms that do the equivalent of the build settings property. And I can easily envision being able to update the Makefile with a list of resources in the project either directly in the file if we have a good parse tree for it, or in a makefile fragment that gets included.

I'm glad you guys are still interested in the build model torch. Maybe the conclusion here is that I spend some time working on the Makefile project side to make them more useful, but do that in parallel with the build model fix up. As I dealve more into the embedded Linux world with autoconf and other Makefile based build systems, I see the need to improve the CDT in these environments.

Doug

On Thu, May 21, 2009 at 11:15 AM, James Blackburn <jamesblackburn@xxxxxxxxx> wrote:

I agree with Chris.  Half my users use Standard Make with Make
targets; the other half, without legacy makefiles to support, are
using managed build successfully.

> 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.

I only complained as the internal builder kept playing up for me :).
Perhaps it's better now. Certainly I think the future has the
automatic internal builder getting as close to the Java builder
performance as we can, and that's something I'm willing to help with!

I think there's immense value in supporting both.  If the Makefile
editor and API gets better, that's great, I'll certainly use it. But I
_also_ really like the fact that you can drop a bunch of source files
in and have them "just build".  Teaching users make would be harder
than teaching them to edit settings in the project properties dialog.

I know managed build gets knocked about a bit. And as untidy as the
API / implementation is, it does have lots of users in the real world
for whom it just works.

Cheers,
James

>
> ===========================
> 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