Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] build console code location

Maybe it's not a problem any more ( I was not monitoring changes in this area last time), but I guess that a placing of console code in UI plugin could be a cause of a big pain for those who implement headless application with console output.


On 13/12/2009 1:45 PM, Doug Schaefer wrote:
As the new build system takes shape, we can eventually move it to the plugins. The relationship between the make and managedbuilder plugins right now is a little tough to figure, so I'd prefer not to make the change now.


On Sun, Dec 13, 2009 at 1:35 PM, Andrew Gvozdev < <>> wrote:

        Guys, please help resolving this problem, because I'm
        completely blocked making patches

        while build console is in cdt.ui.

    As I already stated my opinion on a few occasions, Build Console
    should not belong to cdt.core but to one of build packages. In my
    opinion the most approprate place is cdt.make package. My
    reasoning is following:

    The current hierarchy goes like that:

    cdt.make.core <- cdt.make.ui
    cdt.managedbuilder.core <- cdt.managedbuilder.ui

    The console is used in both make.core and managedbuilder.core via
    IConsole interface. As far as I see IConsole is only used for
    Build Console notion.

    Currently managedbuilder took over "new" manaded builds and
    Makefile project build (which is just a flavor of a managed
    project). However, old style projects and their build live dormant
    in cdt.make plugins. Although you cannot create those in vanilla
    CDT installation, they are pretty much alive and still being used
    by some third party plugins. (As a side note: We can say that we
    don't support those but we should still keep them operational.)

    So, in my opinion, Build Console belongs to cdt.make.* packages.

    As far as architecture, I stated my vision in bug 296935 New CDT
    Build System <>:

        Doug provided several good examples how the build model would
        be used. I'd like to provide in some sense a counter-example
        to illustrate some thoughts about architecture:

        There is a certain category of users who need indexer code
        navigation but are not interested in any build. They just use
        CDT for editing C/C++ files. I would go that far as state that
        well engineered architecture would allow to do that without
        installing build plugins and any overhead related to build system.

        One corollary of that is that cdt.core plugin currently is
        bloated with features which should really be in other plugins.
        Just look at its size. Such features as error parsers, build
        console etc. should be in build plugin(s) rather then in core.
        I am thinking of a build system as being multi-layered where
        each next layer is built on top of another. One layer is core
        which provides core functions but none of related to build.
        Next one would provide general build facilities such as build
        console, error parsers, unmanaged build, scanner discovery (in
        that view it would be cdt.make plugin which is sadly declared
        dead). Finally, managedbuilder plugin which provides the means
        of generating makefiles. Different managedbuilders like Ed's
        middle ground builder could be created as well.

    Doug, since I think that may contradict the direction you are
    taking for the new new build it would be nice if you (and anyone
    interested) could comment on that before we started moving.


    2009/11/30 Dmitry Kozlov <ddk@xxxxxxxxxxxxxxxx

        As Andrew Gvozdev wrote to me commenting one of build console

        "- The name of build output file is being set in Builder
        Settings Tab (which is
        good). However, the Builder Settings are per configuration, so
        the file name
        needs to be stored per configuration as well. It should not be
        kept in
        .project. .project/.cproject could be shared via code
        repository and I don't
        think output file name normally belongs there."

        But configuration is part of cdt.managedbuilder.core. So to
        apply all my console enhancements and
        to confirm all Andrew's wishes I need console to depend on
        cdt.make.ui and cdt.managedbuilder.core. So there are two
        possible locations for buildconsole code:
        top-level separate package or part of cdt.managedbuilder.ui.

        Guys, please help resolving this problem, because I'm
        completely blocked making patches
        while build console is in cdt.ui.


        Dmitry Kozlov wrote:

            we were discussing run command toolbar addition to build
            console toolbar.
            The idea is to add fields to build console toolbar which
            enables to run
            build command or some other command.
            This code requires build console to depend on make.core
            because we need
            to use

            MakeBuilderUtil.getBuildDirectory(project, info) and
            MakeBuilderUtil.getBuildDirectoryURI(project, info)
            to get working directory for command (working in other
            directory have no

            and error parser:
            StreamMonitor streamMon = new StreamMonitor(new
            SubProgressMonitor(monitor, 100), cos, last.intValue());
            ErrorParserManager epm = new ErrorParserManager(project,
            workingDirectoryURI, this, info.getErrorParsers());
            ConsoleOutputSniffer sniffer =
                                          stdout, stderr, project,
            workingDirectory, null, this, null);

            Will it be accepted by upstream if I move all build
            console code to


            cdt-dev mailing list
            cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>

        cdt-dev mailing list
        cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>

    cdt-dev mailing list
    cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>

cdt-dev mailing list

Back to the top