New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debug support #858

Merged
merged 1 commit into from May 12, 2016

Conversation

Projects
None yet
5 participants
@mholo65
Member

mholo65 commented May 1, 2016

Solves #114

WIP Debug support. Currently only supports Stable version of Roslyn, the Nightly should be a no brainer, but I wanted to discuss this more in detail before implementing.

Done:

  • Added support for --debug (short -d) argument
  • Added Debug command + all that jazz
  • Added DebugScriptHost, which waits for a debugger to be attached
  • Added RoslynDebugSession, which compiles the cake-script and emits the dll + pdb to a memorystream which is loaded and executed.

I'm not sure about the Roslyn Session and SessionFactory implementations. Refactored out the common bits, but still feels kind of wierd? Any suggestions on this before proceeding with the Nightly version of Roslyn.

ALSO Still lacks Unit Tests, some bits should be refactored to allow testing, e.g. DebugScriptHost..

HOWTO:

  • launch cake.exe with -debug flag. cake.exe cakefile.cake -debug
  • Process will stop in prior to executing script and report Attach debugger to process XYZ to continue
  • Open Visual Studio, open the cake file, add a breakpoint.
  • Open Debug > Attach to Process... and attach to process with PID reported in step 2.
  • Enjoy debugging...
    • Sometimes VS will fail and report "Source not found", if this is the case, close the open cake-file and then from the call stack window right click on the first row and select "Go to source". This should open the source file and everything is fine :) Don't know why VS behaves like this, breakpoint hits, but it can't open source when it's already open.
    • Another nice way is to add System.Diagnostics.Debugger.Break(); to the line where you would like the debugger to break. In this case you can completely skip opening the file in VS, the debugging session will open it automatically once breakpoint is hit.

@patriksvensson patriksvensson changed the title from WIP: Debug support to [WIP] Debug support May 2, 2016

@patriksvensson

This comment has been minimized.

Show comment
Hide comment
@patriksvensson

patriksvensson May 2, 2016

Member

@mholo65

Great job! 👍

Would it be possible to Rename the RoslynSessionFactory to DefaultRoslynSessionFactory and RoslynSession to DefaultRoslynSession, and after that rename AbstractRoslynSessionFactory to just RoslynSessionFactory and AbstractRoslynSession to RoslynSession.

public sealed class DefaultRoslynSessionFactory : RoslynSessionFactory { }
public sealed class DebugRoslynSessionFactory : RoslynSessionFactory { }

public sealed class DefaultRoslynSession : RoslynSession { }
public sealed class DebugRoslynSession : RoslynSession { }

Not sure that Default is a better prefix, but I'm really not a fan of the Abstract prefix.

@gep13 @devlead: Any input on naming?

Member

patriksvensson commented May 2, 2016

@mholo65

Great job! 👍

Would it be possible to Rename the RoslynSessionFactory to DefaultRoslynSessionFactory and RoslynSession to DefaultRoslynSession, and after that rename AbstractRoslynSessionFactory to just RoslynSessionFactory and AbstractRoslynSession to RoslynSession.

public sealed class DefaultRoslynSessionFactory : RoslynSessionFactory { }
public sealed class DebugRoslynSessionFactory : RoslynSessionFactory { }

public sealed class DefaultRoslynSession : RoslynSession { }
public sealed class DebugRoslynSession : RoslynSession { }

Not sure that Default is a better prefix, but I'm really not a fan of the Abstract prefix.

@gep13 @devlead: Any input on naming?

@mholo65

This comment has been minimized.

Show comment
Hide comment
@mholo65

mholo65 May 2, 2016

Member

Thanx! Default/Debug sounds better than current naming. Will wait and see what the others have to say about naming.

Another thing that cane to mind. What about adding #break pre-processor directive that would inject System.Diagnostics.Debugger.Break();? That could be a separate PR though.

Member

mholo65 commented May 2, 2016

Thanx! Default/Debug sounds better than current naming. Will wait and see what the others have to say about naming.

Another thing that cane to mind. What about adding #break pre-processor directive that would inject System.Diagnostics.Debugger.Break();? That could be a separate PR though.

@devlead

This comment has been minimized.

Show comment
Hide comment
@devlead

devlead May 2, 2016

Member

@mholo65 +1 on naming 👍 Any thoughts @gep13?

New preprocessors should as you suggest be part of separate PR, so we keep this one as focused as possible.

Member

devlead commented May 2, 2016

@mholo65 +1 on naming 👍 Any thoughts @gep13?

New preprocessors should as you suggest be part of separate PR, so we keep this one as focused as possible.

@mholo65

This comment has been minimized.

Show comment
Hide comment
@mholo65

mholo65 May 2, 2016

Member

Would you also like to have debug support for experimental (nightly) version of Roslyn as separate PR? It is not yet implemented in this PR.

Member

mholo65 commented May 2, 2016

Would you also like to have debug support for experimental (nightly) version of Roslyn as separate PR? It is not yet implemented in this PR.

@patriksvensson

This comment has been minimized.

Show comment
Hide comment
@patriksvensson

patriksvensson May 2, 2016

Member

@mholo65 I think debug support for experimental Roslyn could be a part of this PR.

Member

patriksvensson commented May 2, 2016

@mholo65 I think debug support for experimental Roslyn could be a part of this PR.

@devlead

This comment has been minimized.

Show comment
Hide comment
@devlead

devlead May 2, 2016

Member

I agree with @patriksvensson, would be great with support for experimental in this pr too.

Member

devlead commented May 2, 2016

I agree with @patriksvensson, would be great with support for experimental in this pr too.

@mholo65

This comment has been minimized.

Show comment
Hide comment
@mholo65

mholo65 May 2, 2016

Member

@patriksvensson @devlead Thanks. I'll fix the naming, add experimental roslyn support and add some unit tests. I'll probably have it by the end of this week.

Member

mholo65 commented May 2, 2016

@patriksvensson @devlead Thanks. I'll fix the naming, add experimental roslyn support and add some unit tests. I'll probably have it by the end of this week.

@gep13

This comment has been minimized.

Show comment
Hide comment
@gep13

gep13 May 3, 2016

Member

Sorry for not replying sooner, had a couple things on...

Yes, I agree with the suggested naming. I really like the idea of the #debug pre processor as well, I think that will help during debugging sessions, but I agree that this should be a separate PR.

This really is great work @mholo65! This is going to make a lot of people very happy! 👍

Member

gep13 commented May 3, 2016

Sorry for not replying sooner, had a couple things on...

Yes, I agree with the suggested naming. I really like the idea of the #debug pre processor as well, I think that will help during debugging sessions, but I agree that this should be a separate PR.

This really is great work @mholo65! This is going to make a lot of people very happy! 👍

Show outdated Hide outdated src/Cake/Scripting/Roslyn/RoslynScriptEngine.cs
private readonly RoslynScriptSessionFactory _stableFactory;
private readonly RoslynNightlyScriptSessionFactory _nightlyFactory;
private readonly RoslynSessionFactory _stableFactory;
private readonly RoslynNightlySessionFactory _nightlyFactory;

This comment has been minimized.

@mholo65

mholo65 May 4, 2016

Member

@patriksvensson hmm, maybe I should keep Script in the new name. RoslynNightlySession sounds ratherh kinky 😄

@mholo65

mholo65 May 4, 2016

Member

@patriksvensson hmm, maybe I should keep Script in the new name. RoslynNightlySession sounds ratherh kinky 😄

This comment has been minimized.

@patriksvensson

patriksvensson May 4, 2016

Member

@mholo65 Lol 😄 Keep the Script 😉

@patriksvensson

patriksvensson May 4, 2016

Member

@mholo65 Lol 😄 Keep the Script 😉

@gep13

This comment has been minimized.

Show comment
Hide comment
@gep13

gep13 May 4, 2016

Member

@mholo65 quick random question... will the debugger within say VSCode also be able to attach to this, in the same way as you can with Visual Studio?

Member

gep13 commented May 4, 2016

@mholo65 quick random question... will the debugger within say VSCode also be able to attach to this, in the same way as you can with Visual Studio?

@mholo65

This comment has been minimized.

Show comment
Hide comment
@mholo65

mholo65 May 4, 2016

Member

@gep13 haven't tried that. But I could investigate.

Edit
@gep13 coreclr-debug (in omnisharp-vscode) gave no luck. Do you know if it's even possible to debug full framework programs in VS Code?

MDbg worked like a charm. Too bad nobody has created an extension for it in VSCode.

Member

mholo65 commented May 4, 2016

@gep13 haven't tried that. But I could investigate.

Edit
@gep13 coreclr-debug (in omnisharp-vscode) gave no luck. Do you know if it's even possible to debug full framework programs in VS Code?

MDbg worked like a charm. Too bad nobody has created an extension for it in VSCode.

Show outdated Hide outdated src/Cake/Scripting/DebugScriptHost.cs
{
var strategy = new DefaultExecutionStrategy(_log);
var message = "Attach debugger to process {0} to continue";
var pid = System.Diagnostics.Process.GetCurrentProcess().Id;

This comment has been minimized.

@mholo65

mholo65 May 6, 2016

Member

@patriksvensson any wishes for abstracting this in order to unit test?

@mholo65

mholo65 May 6, 2016

Member

@patriksvensson any wishes for abstracting this in order to unit test?

Show outdated Hide outdated src/Cake/Scripting/DebugScriptHost.cs
_log.Information("Performing debug...");
_log.Information(Verbosity.Quiet, string.Format(message, pid));
while (!System.Diagnostics.Debugger.IsAttached)

This comment has been minimized.

@mholo65

mholo65 May 6, 2016

Member

@patriksvensson any wishes for abstracting this in order to unit test?

@mholo65

mholo65 May 6, 2016

Member

@patriksvensson any wishes for abstracting this in order to unit test?

This comment has been minimized.

@patriksvensson

patriksvensson May 9, 2016

Member

@mholo65 Sorry for not answering this until now but I was busy having a wonderful weekend in your lovely country visiting Helsinki and was completely disconnected 😄

I think it would make sense here to add a IDebugger abstraction.

public interface IDebugger
{
  int GetProcessId();
  bool WaitForAttach(TimeSpan timeout);
}
@patriksvensson

patriksvensson May 9, 2016

Member

@mholo65 Sorry for not answering this until now but I was busy having a wonderful weekend in your lovely country visiting Helsinki and was completely disconnected 😄

I think it would make sense here to add a IDebugger abstraction.

public interface IDebugger
{
  int GetProcessId();
  bool WaitForAttach(TimeSpan timeout);
}

This comment has been minimized.

@mholo65

mholo65 May 9, 2016

Member

@patriksvensson no problem at all. Saw on twitter that you was on vacation so I wasn't expecting any response until now.

I would assume that the interface and implementation should then be added to namespace _Cake.Diagnostics_

@mholo65

mholo65 May 9, 2016

Member

@patriksvensson no problem at all. Saw on twitter that you was on vacation so I wasn't expecting any response until now.

I would assume that the interface and implementation should then be added to namespace _Cake.Diagnostics_

This comment has been minimized.

@patriksvensson

patriksvensson May 9, 2016

Member

@mholo65 Yes, that sounds good to me.

@patriksvensson

patriksvensson May 9, 2016

Member

@mholo65 Yes, that sounds good to me.

@mholo65

This comment has been minimized.

Show comment
Hide comment
@mholo65

mholo65 May 9, 2016

Member

@patriksvensson I think I'm confident enough to remove the [WIP] tag now 😄

//cc @devlead @gep13

Member

mholo65 commented May 9, 2016

@patriksvensson I think I'm confident enough to remove the [WIP] tag now 😄

//cc @devlead @gep13

@mholo65 mholo65 changed the title from [WIP] Debug support to Debug support May 9, 2016

@gep13

This comment has been minimized.

Show comment
Hide comment
@gep13

gep13 May 9, 2016

Member

Damn! Really looking forward to taking a look at this, and having a play!

@mholo65 on a side note, did you take a look at using VSCode as the debugger? Is that going to work, or is additional work required? Cheers!

Member

gep13 commented May 9, 2016

Damn! Really looking forward to taking a look at this, and having a play!

@mholo65 on a side note, did you take a look at using VSCode as the debugger? Is that going to work, or is additional work required? Cheers!

@mholo65

This comment has been minimized.

Show comment
Hide comment
@mholo65

mholo65 May 10, 2016

Member

@gep13 I checked up on VSCode debugging and unfortunately it won't work until Cake is ported to .NET Core as the Omnisharp VSCode Debugger uses CLRDBG which is designed for .NET Core.

However, the .NET Framework Command-Line Debugger, MDbg works like a charm. But this debugger is unfortunately not available as an extension for VSCode.

A third alternative is the Mono debugger, which may work. I'm currently not in a position to test that as I'm lacking an environment atm. (read not supported on Windows)

Member

mholo65 commented May 10, 2016

@gep13 I checked up on VSCode debugging and unfortunately it won't work until Cake is ported to .NET Core as the Omnisharp VSCode Debugger uses CLRDBG which is designed for .NET Core.

However, the .NET Framework Command-Line Debugger, MDbg works like a charm. But this debugger is unfortunately not available as an extension for VSCode.

A third alternative is the Mono debugger, which may work. I'm currently not in a position to test that as I'm lacking an environment atm. (read not supported on Windows)

@mholo65

This comment has been minimized.

Show comment
Hide comment
@mholo65

mholo65 May 10, 2016

Member

@gep13 and forget the third alternative as we don't do the Roslyn dance on Linux/Mac and this PR doesn't implement debugging support for Mono...

Member

mholo65 commented May 10, 2016

@gep13 and forget the third alternative as we don't do the Roslyn dance on Linux/Mac and this PR doesn't implement debugging support for Mono...

@patriksvensson

This comment has been minimized.

Show comment
Hide comment
@patriksvensson

patriksvensson May 10, 2016

Member

@mholo65 Awesome work! Really impressed. Will take a closer look at it tonight when I'm off work.

@gep13 Have you seen the Mono debug adapter? https://github.com/Microsoft/vscode-mono-debug

Member

patriksvensson commented May 10, 2016

@mholo65 Awesome work! Really impressed. Will take a closer look at it tonight when I'm off work.

@gep13 Have you seen the Mono debug adapter? https://github.com/Microsoft/vscode-mono-debug

Show outdated Hide outdated src/Cake/Scripting/Roslyn/Nightly/DebugRoslynNightlyScriptSessionFactory.cs
namespace Cake.Scripting.Roslyn.Nightly
{
using Core.IO;

This comment has been minimized.

@devlead

devlead May 12, 2016

Member

Any special reason this isn't by the other using statements above? If not move up so all in one place.

@devlead

devlead May 12, 2016

Member

Any special reason this isn't by the other using statements above? If not move up so all in one place.

Show outdated Hide outdated ...ake/Scripting/Roslyn/Nightly/DefaultRoslynNightlyScriptSessionFactory.cs
namespace Cake.Scripting.Roslyn.Nightly
{
using Core.IO;

This comment has been minimized.

@devlead

devlead May 12, 2016

Member

Any special reason this isn't by the other using statements above? If not move up so all in one place.

@devlead

devlead May 12, 2016

Member

Any special reason this isn't by the other using statements above? If not move up so all in one place.

Show outdated Hide outdated src/Cake/Scripting/Roslyn/Stable/DebugRoslynScriptSessionFactory.cs
namespace Cake.Scripting.Roslyn.Stable
{
using Core.IO;

This comment has been minimized.

@devlead

devlead May 12, 2016

Member

Any special reason this isn't by the other using statements above? If not move up so all in one place.

@devlead

devlead May 12, 2016

Member

Any special reason this isn't by the other using statements above? If not move up so all in one place.

Show outdated Hide outdated src/Cake/Scripting/Roslyn/Stable/DefaultRoslynScriptSessionFactory.cs
namespace Cake.Scripting.Roslyn.Stable
{
using Core.IO;

This comment has been minimized.

@devlead

devlead May 12, 2016

Member

Any special reason this isn't by the other using statements above? If not move up so all in one place.

@devlead

devlead May 12, 2016

Member

Any special reason this isn't by the other using statements above? If not move up so all in one place.

@@ -10,15 +10,15 @@ namespace Cake.Scripting.Roslyn.Stable
{
using Core.IO;

This comment has been minimized.

@devlead

devlead May 12, 2016

Member

Looks like this always been here, @patriksvensson any special reason for separating the usings?

@devlead

devlead May 12, 2016

Member

Looks like this always been here, @patriksvensson any special reason for separating the usings?

This comment has been minimized.

@gep13

gep13 May 12, 2016

Member

@devlead @patriksvensson I am going to guess that this is ReSharper and StyleCop getting in the way of each other. By default, StyleCop wants the usings within the namespace. As a result, if you do an ALT + ENTER, depending on your setup, it will add any "new" using statements within the namespace. This happens to me all the time, and most times I remember to fix it. I think there should be a setting we could add to the ReSharper settings file for the project to specify that usings are outside the namespace.

@gep13

gep13 May 12, 2016

Member

@devlead @patriksvensson I am going to guess that this is ReSharper and StyleCop getting in the way of each other. By default, StyleCop wants the usings within the namespace. As a result, if you do an ALT + ENTER, depending on your setup, it will add any "new" using statements within the namespace. This happens to me all the time, and most times I remember to fix it. I think there should be a setting we could add to the ReSharper settings file for the project to specify that usings are outside the namespace.

This comment has been minimized.

@mholo65

mholo65 May 12, 2016

Member

@devlead yep, all of the above have been like this, it just got duplicated when i splitted it into and abstract class + derived classes. If it's possible to move it outside the namespace, then I'll move them.

@mholo65

mholo65 May 12, 2016

Member

@devlead yep, all of the above have been like this, it just got duplicated when i splitted it into and abstract class + derived classes. If it's possible to move it outside the namespace, then I'll move them.

This comment has been minimized.

@mholo65

mholo65 May 12, 2016

Member

@devlead @patriksvensson @gep13 found the reason. I'ts either this or remove the using Nuget; since IFileSystem will become ambigious.

Which one do you want? Keep using Core.IO; inside namespace or remove using Nuget; and prefix all Nuget references with global::Nuget. (The latter is how it's done inside Scripting with Roslyn)

@mholo65

mholo65 May 12, 2016

Member

@devlead @patriksvensson @gep13 found the reason. I'ts either this or remove the using Nuget; since IFileSystem will become ambigious.

Which one do you want? Keep using Core.IO; inside namespace or remove using Nuget; and prefix all Nuget references with global::Nuget. (The latter is how it's done inside Scripting with Roslyn)

This comment has been minimized.

@devlead

devlead May 12, 2016

Member

@mholo65 Then I think we can let it stay as is for now and perhaps look at refactoring later.

@devlead

devlead May 12, 2016

Member

@mholo65 Then I think we can let it stay as is for now and perhaps look at refactoring later.

Show outdated Hide outdated src/Cake/Commands/DebugCommand.cs
{
throw new ArgumentNullException("options");
}
_scriptRunner.Run(_host, options.Script, options.Arguments);

This comment has been minimized.

@devlead

devlead May 12, 2016

Member

Currently it will crash if break point isn't an task as the debugger isn't attached until tasks are executed.
image

I.e. if I start the script with a System.Diagnostics.Debugger.Break(); at root level.

Did a quick test by adding this before the _scriptRunner.Run(_host, options.Script, options.Arguments);

            if (!System.Diagnostics.Debugger.IsAttached)
            {
                System.Diagnostics.Debugger.Launch();
            }

This will launch the visual studio debug selector:
image

Then break at the launch
image

F5 will take you to the "root level" Break and all works from there
image

@cake-build/team & @mholo65 what do you think perhaps makes sense to move DebugScriptHost::RunTarget to DebugCommand::Execute?

@devlead

devlead May 12, 2016

Member

Currently it will crash if break point isn't an task as the debugger isn't attached until tasks are executed.
image

I.e. if I start the script with a System.Diagnostics.Debugger.Break(); at root level.

Did a quick test by adding this before the _scriptRunner.Run(_host, options.Script, options.Arguments);

            if (!System.Diagnostics.Debugger.IsAttached)
            {
                System.Diagnostics.Debugger.Launch();
            }

This will launch the visual studio debug selector:
image

Then break at the launch
image

F5 will take you to the "root level" Break and all works from there
image

@cake-build/team & @mholo65 what do you think perhaps makes sense to move DebugScriptHost::RunTarget to DebugCommand::Execute?

This comment has been minimized.

@mholo65

mholo65 May 12, 2016

Member

@devlead Yep, that's probably only solution if one wants to debug prior to RunTarget, which one most probably wants 😄

By doing this change, a separate DebugScriptHost shouldn't be needed anymore, it's fine with the default BuildScriptHost.

@mholo65

mholo65 May 12, 2016

Member

@devlead Yep, that's probably only solution if one wants to debug prior to RunTarget, which one most probably wants 😄

By doing this change, a separate DebugScriptHost shouldn't be needed anymore, it's fine with the default BuildScriptHost.

This comment has been minimized.

@devlead

devlead May 12, 2016

Member

@mholo65 yes makes total sense, go with that. Other than this looks epic 👍
Ping us once you adjusted, rebased and squashed into 1 commit and I'll review for merging.

@devlead

devlead May 12, 2016

Member

@mholo65 yes makes total sense, go with that. Other than this looks epic 👍
Ping us once you adjusted, rebased and squashed into 1 commit and I'll review for merging.

This comment has been minimized.

@patriksvensson

patriksvensson May 12, 2016

Member

I think we should wait with launching the debugger until later. Waiting for attachment is probably OK for this PR and then we can expand on this. What do you think?

@patriksvensson

patriksvensson May 12, 2016

Member

I think we should wait with launching the debugger until later. Waiting for attachment is probably OK for this PR and then we can expand on this. What do you think?

This comment has been minimized.

@devlead

devlead May 12, 2016

Member

@patriksvensson yes agree, but we should do wait in debug command execute and not RunTarget to fully enable debugging otherwise non task based code can't be debugged. i.e. arguments/global variables/etc.

@devlead

devlead May 12, 2016

Member

@patriksvensson yes agree, but we should do wait in debug command execute and not RunTarget to fully enable debugging otherwise non task based code can't be debugged. i.e. arguments/global variables/etc.

This comment has been minimized.

@mholo65

mholo65 May 12, 2016

Member

@patriksvensson @devlead yep, a --debug-launch switch could be useful and should be added in another PR... I'll open up an issue to track that.

@mholo65

mholo65 May 12, 2016

Member

@patriksvensson @devlead yep, a --debug-launch switch could be useful and should be added in another PR... I'll open up an issue to track that.

This comment has been minimized.

@patriksvensson

patriksvensson May 12, 2016

Member

@devlead I agree. It should be done in command execute 😄

@mholo65 Perfect!

@patriksvensson

patriksvensson May 12, 2016

Member

@devlead I agree. It should be done in command execute 😄

@mholo65 Perfect!

This comment has been minimized.

@gep13

gep13 May 12, 2016

Member

:shipit:

This comment has been minimized.

@mholo65

mholo65 May 12, 2016

Member

🍰

@mholo65

This comment has been minimized.

Show comment
Hide comment
@mholo65

mholo65 May 12, 2016

Member

ping @devlead @patriksvensson @gep13 fixed, rebased and squashed!

Member

mholo65 commented May 12, 2016

ping @devlead @patriksvensson @gep13 fixed, rebased and squashed!

@patriksvensson

This comment has been minimized.

Show comment
Hide comment
@patriksvensson

patriksvensson May 12, 2016

Member

@mholo65 Looks good to me! 😄

@devlead Will you take lead on this?

Member

patriksvensson commented May 12, 2016

@mholo65 Looks good to me! 😄

@devlead Will you take lead on this?

@devlead

This comment has been minimized.

Show comment
Hide comment
@devlead

devlead May 12, 2016

Member

@patriksvensson agree 👍 Just waiting for CI to complete.

Member

devlead commented May 12, 2016

@patriksvensson agree 👍 Just waiting for CI to complete.

@mholo65

This comment has been minimized.

Show comment
Hide comment
@mholo65

mholo65 May 12, 2016

Member

@devlead seems like Travis osx build is stalled.. :(

Member

mholo65 commented May 12, 2016

@devlead seems like Travis osx build is stalled.. :(

@devlead

This comment has been minimized.

Show comment
Hide comment
@devlead

devlead May 12, 2016

Member

@mholo65 I've restarted the Travis build.

Member

devlead commented May 12, 2016

@mholo65 I've restarted the Travis build.

@devlead devlead merged commit f75166c into cake-build:develop May 12, 2016

4 of 5 checks passed

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
ci/bitrise/7a9d707b00881436/pr Passed on Bitrise - OSX Cake
Details
ci/bitrise/b811c91a26b1ea80/pr Passed on Bitrise - Ubuntu Cake
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuousintegration/teamcity Finished TeamCity Build Cake :: Cake Develop : Tests passed: 2788
Details
@devlead

This comment has been minimized.

Show comment
Hide comment
@devlead

devlead May 12, 2016

Member

@mholo65 This is now merged 👍 Big thanks for your contribution!

@cake-build/team FYI 1/2 travis builds didn't complete(the Mac build - restarted 4 times), all other CI success and tested locally, so took decision to merge anyway.

Member

devlead commented May 12, 2016

@mholo65 This is now merged 👍 Big thanks for your contribution!

@cake-build/team FYI 1/2 travis builds didn't complete(the Mac build - restarted 4 times), all other CI success and tested locally, so took decision to merge anyway.

@mholo65 mholo65 deleted the mholo65:debug-support branch May 13, 2016

@mholo65

This comment has been minimized.

Show comment
Hide comment
@mholo65

mholo65 May 13, 2016

Member

@devlead Thank You! It was a pleasure doing this PR 😄

Member

mholo65 commented May 13, 2016

@devlead Thank You! It was a pleasure doing this PR 😄

@devlead devlead referenced this pull request May 13, 2016

Closed

Debugging support #114

@DamianReeves

This comment has been minimized.

Show comment
Hide comment
@DamianReeves

DamianReeves May 26, 2016

Is there any plans on producing a write-up on using this feature. At this point debug support and intellisense are the only things blocking me from adopting cake as my go to build tool.

Is there any plans on producing a write-up on using this feature. At this point debug support and intellisense are the only things blocking me from adopting cake as my go to build tool.

@mholo65

This comment has been minimized.

Show comment
Hide comment
@mholo65

mholo65 May 26, 2016

Member

@DamianReeves yes, there's an issue here cake-build/website#83 to track this.

Member

mholo65 commented May 26, 2016

@DamianReeves yes, there's an issue here cake-build/website#83 to track this.

@devlead

This comment has been minimized.

Show comment
Hide comment
@devlead

devlead May 26, 2016

Member

@mholo65 @DamianReeves there will likely be an intro blog post too shortly.

Member

devlead commented May 26, 2016

@mholo65 @DamianReeves there will likely be an intro blog post too shortly.

@patriksvensson

This comment has been minimized.

Show comment
Hide comment
Member

patriksvensson commented May 26, 2016

@DamianReeves A blog post have been posted about this: http://cakebuild.net/blog/2016/05/debug-cake-file

@gep13

This comment has been minimized.

Show comment
Hide comment
@gep13

gep13 May 27, 2016

Member

@DamianReeves said...
At this point debug support and intellisense are the only things blocking me from adopting cake as my go to build tool.

As a point of curiosity, what are you currently using as your build tool?

Member

gep13 commented May 27, 2016

@DamianReeves said...
At this point debug support and intellisense are the only things blocking me from adopting cake as my go to build tool.

As a point of curiosity, what are you currently using as your build tool?

@DamianReeves

This comment has been minimized.

Show comment
Hide comment
@DamianReeves

DamianReeves May 27, 2016

@gep13 I go back and forth between psake and FAKE

@gep13 I go back and forth between psake and FAKE

@gep13 gep13 referenced this pull request Jun 6, 2016

Closed

Add -debug flag #587

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment