Figgle Generator not creating strings. about figgle

[drewnoakes]

Does your StartupBanners class include a Development property?

To see generated files you need to set the EmitCompilerGeneratedFiles property in your project:

<PropertyGroup>
    <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
</PropertyGroup>

This will write a file to a location such as obj/Debug/net8.0/generated/MyProject.Lib.Common.

Note that source generators don't write this file by default for performance reasons. The disk IO is avoidable.

[HowardShank]

Thanks for the quick response.

I do not have that in setting configured. I'll test that tomorrow.

So if the string is generated there, how is it usable as a reference in my source elsewhere? Or is the string just something that you go copy and put in your code where you need it?

[drewnoakes]

With the source generator, the output string is computed at compile time, rather than at run time, so it's faster when your program runs (nothing to compute) and you don't need to ship Figgle binaries (which include large font files, embedded).

So your program could resemble this:

[GenerateFiggleTextAttribute("DevelopmentString", "standard", "Development")]
public partial class StartupBanners
{
}

public static class Greeter
{
    public static void PrintDevelopment() => Console.WriteLine(StartupBanners.DevelopmentString);
}

[HowardShank]

Thank you for your help with this. I appreciate it.

How difficult is it to remove all the fonts except one from the runtime package?

[drewnoakes]

It would require some refactoring of the packages I think. You can easily parse a single figlet file using the APIs, but today the core fonts are embedded for convenience.

See #12.

[HowardShank]

Do you mind if I pull the source and give it a shot?

[drewnoakes]

You're welcome to play with it! But if you're hoping to land a change in this repo, I recommend sharing a proposal as to how that might work before submitting a PR. That could save you a bunch of time.

Let's continue the discussion in #12. Looks like the original issue here has been addressed so I'll close this.