Skip to content
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

Unclear module generator usage #996

Closed
fredo514 opened this issue Jan 17, 2025 · 5 comments · Fixed by #1004
Closed

Unclear module generator usage #996

fredo514 opened this issue Jan 17, 2025 · 5 comments · Fixed by #1004
Assignees

Comments

@fredo514
Copy link

fredo514 commented Jan 17, 2025

Hi,

First of all, let me thank you for the impressive tool you put out there and all the improvements added in 1.0.0!

I'm trying to use Ceedling with a non-standard project structure, e.g.:

src/
├─ foo/
│  ├─ foo.h
│  ├─src/
│  │  ├─ foo.c
│  ├─ tests/
│  │  ├─ test_foo.c
├─ bar/
│  ├─ bar.h
│  ├─src/
│  │  ├─ bar.c
│  ├─ tests/
│  │  ├─ test_bar.c

But I can't find the right settings for creating that structure automatically when using ceedling module:create. The closest I got what setting paths to

:paths:
  :test:
    - +:src/**
  :source:
    - +:src/**
  :include:
    - +:src/** # In simple projects, this entry often duplicates :source
  :support:
    - test/support
  :libraries: []

configuring module_generator with:

:module_generator:
  :path_src: src/
  :path_tst: test/
  :naming: :snake

and calling ceedling module:create[foo/foo]. But it doesn't create the sub-directories I want. I.e. it creates:

src/
├─ foo/
│  ├─ foo.h
│  ├─ foo.c
│  ├─ test_foo.c

What am I doing wrong?

Also, the project.yml generated with ceedling new doesn't use the new path variables (path_src, etc) in the :module_generator: config.

@mvandervoord
Copy link
Member

Hi @fredo514 -- thanks for the note at the end. I'll look into that!

I'm afraid that this structure isn't likely to make it easy to use module_generator... particularly since module_generator never creates directories... it just does its best to match your existing directories to the requested path.

Would it be worthwhile for us to add the option to specify where EACH file goes when using this feature?

Otherwise, the best scenario is likely that you create a folder where files are supposed to go initially upon creation and then you move them to the right spot when desired.

You might be able improve it's guesses by getting more specific with the path specification... but I suspect it's not worth it in the long time. You'd just be trading one manual task (moving files to the right place) with another manual task (manually creating folders and then adding to the :path listings in project.yml). That's not really a savings.

That might look something like this:

:paths:
  :test:
    - +:src/**/tests/
  :source:
    - +:src/**/src/
  :include:
    - +:src/** # In simple projects, this entry often duplicates :source
  :support:
    - test/support
  :libraries: []

I'm still not confident it would always do the right thing using the above, but it's worth a try?

@mvandervoord
Copy link
Member

(fixed the project.yml file example issue listed above)

@fredo514
Copy link
Author

Thanks a lot for the answer.

The provided path config indeed works if I create the folder manually before. I found the Vscode extension Template that basically lets me right-click on the src folder, enter a module name, and have the folder created automatically. It's 2 steps, but not the end if the world.

I'm not sure if I understand what you mean by being able to specify the location of each files, but I think it could be useful if the plugin had these features:

  • create folders (maybe by specifying an absolute path instead of a match? e.g. [foo/foo] vs [foo:foo])
  • use the :module_generator: config as an additional path inside the generated module folder for the various file types

@mvandervoord
Copy link
Member

Your first bullet makes sense to me. We have to avoid slashes currently, because of the way the command parser works... but I'm sure we can figure something out.

I'm not sure what you mean by this:

use the :module_generator: config as an additional path inside the generated module folder for the various file types

Are you suggesting that we add new options that would modify whatever path is provided for src, tst, and inc?
Are you suggesting that we should repurpose the existing paths in module_generator somehow?

@fredo514
Copy link
Author

There's surely many intricacies I'm not aware of, so you know best.

Currently, if I use slashes in the module:create command, it creates some subfolders on top of the paths in :module_generator: then places the files in them. Maybe it's an unintentional side-effect of the parser?

If I understand correctly, the paths in :paths: are really just search patterns for Ceedling to find the various project sources?
If it's the case, I understand that :module_generator: can't just append paths to :paths: when creating the files. But then what is the recommended use of the :module_generator: paths as implemented? Because if they don't match with :paths: then Ceedling won't find the new files...

My use case was to have a way to create modules in a project with a non-default directory structure. I really don't know enough of Ceedling's backend or even Ruby to know if it's even possible, but it would be really nice to have. Especially since some vendor tools force their own project directory structure that doesn't match ceedling's default (stm32cube, nordic, etc).

For example, referring to my initial post, I wanted this module structure:

src/
├─ foo/
│  ├─ foo.h
│  ├─src/
│  │  ├─ foo.c
│  ├─ tests/
│  │  ├─ test_foo.c

I'd like to be able to set paths and/or other settings to be able to call ceedling module:create[foo] and get a reasonably arbitrary folder structure.

If you point me in the right direction, maybe I can give it a try and report back with a proof of concept?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants