folder_name needs to match folder_name.ino

[a7hybnj2]

When working on larger projects having to pair the parent folder name to the .ino file is inconvenient. Being able to keep a consistent naming convention...like:

ProjectName(folder)

• README.txt
• Arduino_sketch(folder)
  • DescriptiveName.ino
  • ect.ino
• BoardLayout(folder)
  • schematic.sch
  • layermask.msk
• Photos(folder)
  • completed project.jpg

[J3r3Xy]

I agree. Why do folder and sketch need to have the same name?

[facchinm]

The "same name" policy is being used by the IDE to spot the "main" ino file and show it in the first position. While this is a Processing heritage I still find it quite ok (code first, documentation/data/images in other folders that are ignored by the builder but can be used by other tools).
@per1234 There's probably the same request lying around but I can't find it so if you caould cross-reference them it would be great 🙂

[per1234]

@facchinm I searched without finding any other duplicate issues, open or closed. I have seen a few infrequent complaints about this on the forum and elsewhere.

Without the folder name matching requirement, it would be necessary to add a metadata file to the sketch to record which is the "main" .ino file. I don't think it's worth that extra complexity and loss of backwards compatibility with previous IDE versions simply to allow people to name their folders as they like. Perhaps I would feel differently if the metadata file also provided additional benefits (e.g. associating board and port with a sketch).

[a7hybnj2]

Metadata would be awesome! Or a .conf file or something similar.

[a7hybnj2]

now that the tools are going to arduino-builder and arduino-cli it would be awesome if this could be squeezed in.

[adamkdean]

I see that arduino/arduino-cli#948 was closed with a decline. I think it's the wrong decision. It shouldn't be a difficult thing to add an override flag in, so you can run arduino-cli compile --fqbn $(FQBN) --entrypoint main.cpp firmware etc. I appreciate that there is backwards compatibility to ensure, and ensuring that this plays well with the frontend, but isn't the point of optional arguments that they're optional? If it's a case of needing a PR, I'd be happy to do the work, but is there really a strong objection against such an argument?