fix: build --no-codegen output file name error

[apainintheneck]

This avoids errors based on output file name when the --no-codegen command is passed to crystal build since it shouldn't be necessary to specify an output file if no file will be created anyway.

$ crystal build --no-codegen  example/example.cr
Error: can't use `example` as output filename because it's a directory

This change means that the following lines of code get skipped when using --no-codegen.

crystal/src/compiler/crystal/command.cr

Lines 598 to 601 in bb96c53

	# Check if we'll overwrite the main source file
	if !no_codegen && !run && first_filename == File.expand_path(output_filename)
	error "compilation will overwrite source file '#{Crystal.relative_filename(first_filename)}', either change its extension to '.cr' or specify an output file with '-o'"
	end

crystal/src/compiler/crystal/command.cr

Lines 611 to 613 in bb96c53

	if !no_codegen && !run && Dir.exists?(output_filename)
	error "can't use `#{output_filename}` as output filename because it's a directory"
	end

It will also means that we skip the combine rpaths step.

crystal/src/compiler/crystal/command.cr

Line 619 in bb96c53

combine_rpath = run && !no_codegen

[straight-shoota]

Hey @apainintheneck, thanks for picking this up! 👋

This PR looks all right, as in it should probably work. But I'm a bit concerned about the semantics and wondering if there couldn't be a better solution.
The reason is that no_codegen is an input parameter and it feels a bit sketchy to change its value somewhere down the line. It will probably work fine because all the relevant code that uses it as the original input parameter is in the initial setup that and that has already executed at this point. So it's not used for that anymore.

Yet, wie have some duplication with compiler.no_codegen which contains the configuration value. So I'm thinking maybe instead we could replace all references to no_codegen by compiler.no_codegen in the subsequent code after the option parser setup.
And set compiler.no_codegen = no_codegen at the top of the method.
Then there would be a clear separation: no_codegen is only responsible for the CLI configuration. compiler.no_codegen determines if codegen is actually enabled in the compiler.

Does this make sense to you?

[apainintheneck]

Yet, wie have some duplication with compiler.no_codegen which contains the configuration value. So I'm thinking maybe instead we could replace all references to no_codegen by compiler.no_codegen in the subsequent code after the option parser setup. And set compiler.no_codegen = no_codegen at the top of the method. Then there would be a clear separation: no_codegen is only responsible for the CLI configuration. compiler.no_codegen determines if codegen is actually enabled in the compiler.

Does this make sense to you?

This makes sense to me. It shouldn't change semantics like you said but it will make the code easier to reason about.