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

Implement Project setup for different Targets #5

Open
tanneberger opened this issue Jan 17, 2023 · 8 comments
Open

Implement Project setup for different Targets #5

tanneberger opened this issue Jan 17, 2023 · 8 comments
Assignees
Labels
enhancement New feature or request

Comments

@tanneberger
Copy link
Member

tanneberger commented Jan 17, 2023

Desired behavior

	$ lingo init cpp
	$ lingo init zephyre

Creates Lingo.toml and ./src/main.lf with the correct target set and potentially other needed files.

Help

=> The explanation refers to #6

  • Under ./src/packages/mod.rs is a ConfigFile this struct has a ConfigFile::new() function which generates the struct which is then written into Lingo.toml
  • in the ./src/main.rs are the command line arguments handled and files are currently created there but this can be moved.
  • in the ./src/args.rs is the expected command line argument schema.
@tanneberger tanneberger added the enhancement New feature or request label Jan 17, 2023
@tanneberger tanneberger changed the title Implement Project setup Zephyre Implement Project setup for different Targets Jan 17, 2023
@lhstrh
Copy link
Member

lhstrh commented Jan 17, 2023

Note that zephyr is a platform, not a target, so I think the syntax more likely should be something like lingo init c zephyr.

@erlingrj
Copy link
Collaborator

Will have a look at this during the weekend!

@erlingrj
Copy link
Collaborator

erlingrj commented Jan 23, 2023

An option is to fork this example repo and add some commands to west and a HelloWorld.lf. Then lingo init c --platform=zephyr (or however we want it), will clone the forked repo. A disadvantage is that we are dependent on an external repo

@cmnrd
Copy link
Collaborator

cmnrd commented Jan 24, 2023

For the syntax I like --pltatform= a lot better. Its always easier to understand named arguments. I would even use a required --target= argument instead of the positional argument used above.

@lhstrh
Copy link
Member

lhstrh commented Jan 24, 2023

I agree that the more rigid way of dealing with parameter might be more readable, but it's annoying to type and harder to remember than a quick shorthand. I think we should take a careful look at how recent package managers work and how they deal with arguments.

@lhstrh
Copy link
Member

lhstrh commented Jan 24, 2023

There is something to be said for having a more imperative and readable style of giving commands. I personally like lingo init zephyr a lot more than lingo init --platform=zephyr.

@cmnrd
Copy link
Collaborator

cmnrd commented Jan 24, 2023

The thing with positional arguments is that they are hard to remember. If we mix in the target, e.g. lingo init C zephyr, it becomes hard to read and understand. In this example it is clear what is the language and what the platform, but there surely are possible pairs where it is not so obvious. And also when typing, you always have to remember both the order and the meaning of the positional arguments, while with --target and --platform you only need to know that you want to give a target and a platform, but do not need to worry about the order.

@lhstrh
Copy link
Member

lhstrh commented Jan 24, 2023

I get your point./ Still, I think we should resist the temptation to achieve too much generality with what one can specify on the command line. After all, we have a configuration file, which is much easier to edit than configure using an elaborate command that inevitably will start to look like the o figuration file itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants