Author Topic: [Announcemend] New plugin: cbBuiltTools  (Read 696 times)

Offline BlueHazzard

  • Lives here!
  • ****
  • Posts: 2025
[Announcemend] New plugin: cbBuiltTools
« on: April 12, 2018, 01:29:04 am »
Hi,
i created a new plugin and would like to show it here:
https://github.com/bluehazzard/cbBuildTools

This plugin will add additional UI to the build process of codeblocks. At the moment only a "target window" is implemented. This window shows all targets in a tree control and allows you by double clicking to build this target. This allows a fast building of different targets.

This plugin is in heavy development and i will change the functionality and or the UI a lot in the near future.

And critique is welcome!

thanks

[edit:] Unix projects will follow tomorrow...

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11134
    • Travis build status
Re: [Announcemend] New plugin: cbBuiltTools
« Reply #1 on: April 12, 2018, 02:11:11 am »
I hope you're aware that the code below will break the moment we introduce -fvisibility-hidden to build options.
Also be aware that dynamic_cast doesn't work for dlopened shared libraries on linux (don't know if you've tried it already...).

Code: [Select]
CompilerGCC* compiler = dynamic_cast<CompilerGCC*>(Manager::Get()->GetPluginManager()->FindPluginByName(_("Compiler")));
compiler->Build(target);

The proper way to implement this is by adding the appropriate method to the cbCompilerPlugin class...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline BlueHazzard

  • Lives here!
  • ****
  • Posts: 2025
Re: [Announcemend] New plugin: cbBuiltTools
« Reply #2 on: April 12, 2018, 11:50:48 am »
Quote
I hope you're aware that the code below will break the moment we introduce -fvisibility-hidden to build options.
Also be aware that dynamic_cast doesn't work for dlopened shared libraries on linux (don't know if you've tried it already...).
I know that this is a bad solution and no i have not tested it on linux yet. Thank you for the hint!

How do i come from a compiler ID (or better build target) to the corresponding compiler plugin? There seems no connection between
Code: [Select]
class Compiler <-> class cbCompilerPlugin
if i look at the debugger plugin it simply uses the first compiler it can find:
Code: [Select]
  // make sure the target is compiled
        const std::vector<cbCompilerPlugin*> &compilers = Manager::Get()->GetPluginManager()->GetCompilerPlugins();
        if (compilers.empty())
            m_pCompiler = nullptr;
        else
            m_pCompiler = compilers.front();
        if (m_pCompiler)
        {
            // is the compiler already running?
            if (m_pCompiler->IsRunning())
            {
                Log(_("Compiler in use..."));
                Log(_("Aborting debugging session"));
                cbMessageBox(_("The compiler is currently in use. Aborting debugging session..."),
                             _("Compiler running"), wxICON_WARNING);
                return false;
            }

            Log(_("Building to ensure sources are up-to-date"));
            m_WaitingCompilerToFinish = true;
            m_pCompiler->Build();
            // now, when the build is finished, DoDebug will be launched in OnCompilerFinished()
        }
Is this really the right way? Shouldn't the build process be called from a central instance, that knows the association between compiler id and compiler plugin?
I know at the moment there is only one central compiler plugin, but the API seems to suggest that there are multiple compiler plugins available, so this does not seem to be consequent...

Anyway, i will use the debugger way for now. Thank you again, you probably saved me a lot debugging work on linux.