On 4/26/2010 2:47 PM, Doug Schaefer wrote:
Check out
org.eclipse.cdt/windows/org.eclipse.cdt.msw.build first. This used to
work a couple of years ago.
I also have hope for a MSVC debugger in TCF. Eugene has
implemented a working Windows debugger there. We just need to integrate
that with EDC.
I would also skip VS Express and go directly to the Windows SDK,
which includes all of the compilers and nmake as well as a recent
debugging tools for windows.
Thanks for the info! I will look into this more seriously once 7.0 is
out.
On Mon, Apr 26, 2010 at 2:40 PM, Michael
Jackson <mike.jackson@xxxxxxxxxxxxxx>
wrote:
Are
you going to have MSVC debugger integration as well?
VS Express does include NMake but does NOT include support for
building 64 bit apps (if that really matters, but FYI).
You may want to look at the CMake project as they generate .sln and
.project files for Visual Studio users. There is a lot of work that
goes into the generators and getting them "right" is sometimes very
tricky. I do wish you luck in your endeavor.
___________________________________________________________
Mike Jackson
Thanks for the comments. I would like to have debugger integration as
well but my priority is building first. I thought about CMake but it
would be great to provide support without additional tools.
On Apr 26, 2010, at 2:24 PM, Marc-Andre Laperle
wrote:
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
|