Auto config

On the auto-config branch, you can see an auto directory, as well as inside a python script auto-enable-ir-emitter.py that will test each configuration of config.json. If the C script runs without error, the user should confirm that the infrared emitter is working. If yes, the python script proposes to create the systemd service.

I will test the program a few more days and if there are no problems I will merge it with the master Edit: the branches have been merged

@renyuneyun You proposed to make an AUR package, personally I’m on Manjaro but I don’t know if I’m going to be there for long, so it might be better if you took care of it. I don’t know if I should create a new repo? Or this one is enough and I put you as a collaborator? Or we use your repo, I don’t mind.

Any other help or comment is of course welcome.

[EmixamPP]

I’m fine with you keeping the package. Conversely, if you prefer to give it to me, there is no problem!

In the future I plan to develop an even more advanced configuration tool (which will only require a few manipulations and will be able to configure any camera). But I still need to gather my ideas and information so that I don’t overkill something. I’m not sure if I’m going to be able to do this, but I’ll have to do it myself, and I’m not sure if I’m going to be able to do this. And it will probably be a complete program. Maybe a graphic sotware, so that it is extremely easy to use. (And maybe more in the spirits of “Windows” than “Linux”.)

So, to answer your question, I think that in the future the package could change. I tend to go for a “utility”, rather than a script that runs silently in the background.

However, I think I’ll keep every possibility in the future. Since the manual configuration requires no maintenance for me. And the current automatic one, I just have to add lines in a YAML file which is not very long. This way everyone can continue to find what they are looking for.

[renyuneyun]

I’m reporting back after testing it. First of all, I have no comment about the C code itself, because it works perfectly on my machine.

The “auto” scrip also works fine. But in my understanding, the “auto” script is on the opposite of what is expected in a package… I mean, it is meant to interactively perform everything for compiling and configuring, and even tries to modify /. This is useful for human-watched installation, but doesn’t work well for automatic building and installation. It will also make it hard to uninstall this application.

I can imagine a quick “fix” resulting in a new procedure like this:

1. Make the auto-config script try different settings, and print the expected one out.
2. Have a configuration file containing the expected arguments that are printed out by the auto-config script.
3. When executing the main program, read from the configuration file, and perform accordingly.
4. Change the .service file to run the main program directly, rather than having the exact arguments in it.

In this way, the packaging process can be:

1. Compile the main program
2. Include the auto-config in the package
3. Include the main program in the package
4. Include the .service file in the package
5. (Optionally) Include a dummy/default configuration file in the package
6. (Optionally) When installing the package, print a message asking the user to run the auto-config first, and then add the information to the configuration file

Therefore, when the user installs the package, what he needs to do is:

1. Execute the auto-config provided.
2. Add the printed configuration to the configuration file.
3. Execute the main program or enable/start the service.

In this way, only 1 file needs to the modified by the user (automatically or manually, which can be discussed), which is the configuration file. In my understanding, this aligns a lot better to packages in the Linux world.

How do you feel about that?