Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] MSVC (was Build Again)

Hi Doug,

BTW, I'll try to integrate MSVC for CDT 7.1/8.0. I'm considering two use cases:

1. Use NMAKE for Standard Makefile projects and Managed projects. Generate Makefiles NMAKE will understand.
2. To provide full compatibility with VS, use devenv.exe to build solutions and maintain the .sln file and .vcproj files. Only supported with VS installations. This one could be tricky.

The toolchain could be obtained from:
1. VS installation
2. WinDDK
3. VS Express (I have to check if it includes NMAKE)

Do I have to worry about any legal stuff? Can I just copy over the compiler and linker options from VS?

Thanks

Marc-Andre

On 4/26/2010 11:13 AM, Doug Schaefer wrote:
On Mon, Apr 26, 2010 at 12:37 AM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:
Hi Doug,
I think currently standard make project is hurt being an instance of an overweight MBS project. MBS took over everything related to build including project model squashing any competitor build system with impenetrable complexity. If we could make MBS a build system among others it would be a good thing. MBS is very useful and working well for the most part, but those parts that are not working properly, such as scanner discovery, near impossible to fix.

A while ago I wrote a prototype for new scanner discovery (bug 290631). For all the talk I never got much feedback on that. I planned to continue that work after Helios release. Perhaps I can give you a hand with the new build system on scanner discovery along these ideas? And if it proves itself we could back-port it back to MBS.

Sorry I missed this Andrew, I will definitely take a look. I want to make sure scanner discovery, which is critical for Makefile projects, is easily extensible to other tool chains, cross gcc compilers in particular and MSVC probably to ensure we're not too gcc specific. I like the fundamentals of scanner discovery, i.e. build output parsing and collecting like compiler commands to ensure we can have scalable per file discovery. But we need make it easier to extend.


BTW, perhaps you could create a git repository for the new-build plugin rather than CVS - to try it out before potential move of CDT ones?

That's a good idea. I need to keep track of egit and using for something real will help. I have an account on github and will set up something there.

My strategy is to have a build.core and build.ui plug-in where we can fork what we need so that we don't disturb existing stuff and to help break the shackles. Scanner discovery should be one of those things. It'll also have a new New Project wizard to set up the project for the new build system.
 

Andrew


On Sat, Apr 24, 2010 at 4:26 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
Thanks guys. I'll definitely use your input.

I will disagree with James statement that "it works today". I never been able to get scanner discovery to work for a new toolchain. I know Chris R has had a similar problem. If it did work today I wouldn't be so frustrated by it. And I think the problem is architectural, not code quality. Standard make projects used to be very simple. Yes, we needed them to do more, but they still should be simple.

My focus will be on making it easier to get projects that use Makefiles and/or external managed build systems like configure, qmake, and cmake up and running including automatically setting up build environments and scanner discovery. I certainly won't be replacing CDT's managed build in the short term. It works well enough, and I only have so many hours to spend on this. And given the pervasiveness and quality of Make and the external managed build systems, I'm not even sure it's needed any more.

:D


On Sat, Apr 24, 2010 at 2:02 PM, Treggiari, Leo <leo.treggiari@xxxxxxxxx> wrote:
Putting together a fully customizable managed build system was complex and I guess it shows.

See http://www.ddj.com/dept/opensource/197002115 for an exaqmple of its flexibility.

That said, I would suggest that the first step is this.  Cleanly separate the "create a makefile or other build system file" functionality of the MBS from the basic build functionality.  My belief is that all build systems added to CDT can gain by much of the functionality at the TOP of the MBS schema - objects like Projects, Configurations, ToolChains.  The ability to specify information such as how to set up the build environment for a toolchain or provide the information needed by the editing functionality of CDT is invaluable to a multi-toolchain environment such as CDT - even Visual Studio finally provides the ability to set up a tool-chain specific environment in VS 2010.  And, then resolve how Scanner discovery interacts with this basic tool-chain integration functionality - that clearly was never done properly.

The information from the TOP of the MBS schema could be provided in a new schema and the MBS schema evolved to the pieces required for generating a build file or implementing an internal builder.  Or maybe some clean split can be accomplished with the current schema.

Thanks for listening,
Leo

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of James Blackburn
Sent: Saturday, April 24, 2010 9:30 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Build Again

Hi Doug,

You're right: the CDT build-system is tough, the code quality leaves
something to be desired, and the way it's been written makes unit
testing hard, so instead there are brittle end-to-end tests.

That said it works today.

I spent last week fighting to make improvements for a team using
ManagedBuild in anger. One project set has 44 (yes really 44!)
inter-dependent projects. Most are libraries which are brought
together using references to build the top-level app.  It works
remarkably well but a there are a few problems: bug 309769 and
friends...

I worry that years have been put into the current build system, and
that it would be impossible with current resourcing to recreate the
functionality.  And if we were to re-create it, would we just end up
with the same issues and same problems as before?  Taking debug as a
topical example: there are now 3 debug engines, each with pros and
cons and each with committers addressing similar issues. As a user I'm
not really sure why I'd choose one over the other. While it's good
there's choice, in my mind choice creates confusion, and wastes
effort.

The wiki makes some great points.  One thing it doesn't mention is how
to go about solving the complexity of the build model. Currently it's
hugely verbose (in terms of lines of code, size of a .cproject, size
of the build system schema) and a huge PIA to maintain.  I can't help
but feeling that EMF might make this all easier -- if only I knew
anything about it.

Rather than starting from scratch, would it be better to start from
where we are now, work out where the pain-points are and push for
improvements in these areas?  That way we make what we have better
rather than taking the risk of starting from scratch and not having
enough momentum to carry it through.

At the moment I'm pretty invested in the MBS. We have two teams using
it for their projects, and 1 team using Make Targets and standard
make.  Unless the project leads give up on it, I can't see myself
getting much time to work on something completely new.

Cheers,
James


On 24 April 2010 16:05, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
> Hey gang, FYI,
> As I mentioned on the last call, I've been asked to play a more active role
> in TCF and help build a community for it and work with you to bring it to
> maturity. That's taking most of my time these days as I get up to speed and
> figure out what we need to do with it.
> In my spare time, I'm working on bringing the CDT to the Android community
> to help build native libraries for that platform. The focus is on one of my
> dream projects, building a game engine out of open source parts, in this
> case for Android, but I have eyes on iPhone and MeeGo too. Part of doing
> that is getting the Android gnu toolchain working well with CDT. And that's
> brought me back into the CDT build nightmare. Once again, I am having a hell
> of a time getting scanner discovery working for these seemingly simple
> Makefile projects. Just look at a stack trace sometime and you'll see,
> today, the CDT build system is the opposite of simple.
> So I am urging myself to get back into working on a new build system. We
> need to put the architecture back to the way it was, with managed build
> being an add-on, not having everything driven by managed build. Obviously,
> I'm not going to have much time to spend on it, so by definition, I'll have
> to keep it simple. And I'll have to do it as a separate stack, not as an
> evolution of what we have.
> Over the next few days, I'll jot down some more ideas
> here http://wiki.eclipse.org/CDT/NextGenBuild. And I'll recreate cdt.build.*
> plug-ins, this time in a separate folder to avoid confusion. And as always
> help is appreciated and hopefully, I'll have new found vested interest in
> bringing it to completion, especially since I want to get back working on
> the Android project.
> Cheers,
> 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


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

Back to the top