source-dir in fpm.toml must not be an array

[scivision]

Description

It doesn't appear documented, but source-dir of [library] in fpm.toml must be a single value. This should be documented.
It would be preferable to allow an array, but if this is difficult now, at least documenting this would be good.
Right now, FPM simply acts as if no source code is available at all if source-dir is an array, even a length-one array.

Expected Behaviour

I would like to allow source-dir to be an array. If that's not feasible now, at least document that source-dir must not be an array, even a length-one array.

Version of fpm

0.7.0

Platform and Architecture

Windows x86-64, any

Additional Information

No response

[perazz]

@scivision are you expecting to provide multiple source directories, or just different syntactic sugar for fpm.toml i.e. a 1-sized string array?

[minhqdao]

I totally agree that an error should be thrown when a type was entered that can't be mapped.

But it isn't clear to me what the benefit is of having multiple source directories instead putting everything into src and have it tidy and well-structured in there. Having everything in src will ensure a much cleaner top-level directory than if people start having multiple source directories. Someone having a first look at the repo will immediately find the relevant source code without having to dig through the manifest to identify which of the folders contain relevant source code. Many other languages follow that "single source directory approach", calling the directory src or lib.

[perazz]

I was also initially baffled but I found fpm has been supporting multiple folders for include files for a long time. As the aim seems to be easier mixed-language library building, adding this patch at least for library builds would be consistent with the approach AFAICT. @scivision may give us the example of why that would be beneficial.

That said, I'm in favor of more restrictive rules (all sources in src/, all main programs in app/, etc) especially as far as registry packages go live. It will make it much easier for the registry back-end to perform basic checks on the packages.

[perazz]

Hello @minhqdao, I don't see any evidence from this thread that you're against moving forward with this issue and why. Could you please comment on it if you wish?

[minhqdao]

Well, you've perfectly said it yourself in your last comment.

That said, I'm in favor of more restrictive rules (all sources in src/, all main programs in app/, etc)

I absolutely agree to this. Therefore I'm surprised to see you changing that behavior in #847.

@scivision may give us the example of why that would be beneficial.

Just as you, I'm also waiting for arguments why we'd want to change the package layout to support multiple src folders. As long as there aren't any, I still believe that a single src location makes sure that we always have a clean package layout.

[minhqdao]

TODOs in case #847 isn't merged:

• Improve error handling so a sensible message is displayed when a user enters a string
• Fix CLI helper text.

[certik]

Let's only allow a single value for now, and not allow arrays at all (not even single element ones). Let's raise a good error message and let's document it.