How to modify files in post-build script depending on a menuconfig flag? - authentication

I need to find a way to modify/edit a given file after Buildroot compilation and right before the creation of the rootfs depending on a menuconfig flag selection. I could find in the Buildroot documentation that it is possible to do that by using post-build scripts.
My problem is that I would do the script action only if I selected something in menuconfig, for example:
(x) Enable my_login_system;
If I select my_login_system, then I need to change the nsswitch.conf file according:
passwd: my_login files
If I don't select in menuconfig the "my_login_system", then the nsswitch.conf should be:
passwd: files my_login
So, my main question is how to know if the "my_login_system" was selected or not in the post-build script.

When a post-build scripts is executed, it can access the BR2_CONFIG environment variable, which holds the path to the Buildroot .config file. Your script can parse that file and act accordingly.
Thus you could have a condition like:
if grep -q ^BR2_MY_LOGIN_SYSTEM=y ${BR2_CONFIG}
then
# do some tweaks
else
# do other tweaks
fi
Alternatively, you could use the BR2_ROOTFS_POST_SCRIPT_ARGS configuration variable to pass arbitrary command line parameters (as opposed to environment variables) to the post-build scripts.
Both possibilities are documented in the Buildroot manual, at section Customizing the generated target filesystem.

Related

Why are the files called .babelRC and .npmRC? [duplicate]

In my home folder in Linux I have several config files that have "rc" as a file name extension:
$ ls -a ~/|pcregrep 'rc$'
.bashrc
.octaverc
.perltidyrc
.screenrc
.vimrc
What does the "rc" in these names mean?
It looks like one of the following:
run commands
resource control
run control
runtime configuration
Also I've found a citation:
The ‘rc’ suffix goes back to Unix's grandparent, CTSS. It had a command-script feature called "runcom". Early Unixes used ‘rc’ for the name of the operating system's boot script, as a tribute to CTSS runcom.
Runtime Configuration normally if it's in the config directory. I think of them as resource files. If you see rc in file name this could be version i.e. Release Candidate.
Edit: No, I take it back officially... "run commands"
[Unix: from runcom files on the CTSS system 1962-63, via the startup script /etc/rc]
Script file containing startup instructions for an application program (or an entire operating system), usually a text file containing commands of the sort that might have been invoked manually once the system was running but are to be executed automatically each time the system starts up.
Thus, it would seem that the "rc" part stands for "runcom", which I believe can be expanded to "run commands". In fact, this is exactly what the file contains, commands that bash should run.
Quoted from What does “rc” in .bashrc stand for?
I learnt something new! :)
In the context of Unix-like systems, the term rc stands for the phrase "run commands". It is used for any file that contains startup information for a command. It is believed to have originated somewhere in 1965 from a runcom facility from the MIT Compatible Time-Sharing System (CTSS).
Reference: https://en.wikipedia.org/wiki/Run_commands
In Unix world, RC stands for "Run Control".
http://www.catb.org/~esr/writings/taoup/html/ch10s03.html
To understand rc files, it helps to know that Ubuntu boots into several different runlevels. They are 0-6, 0 being "halt", 1 being "single-user", 2 being "multi-user"(the default runlevel), etc. This system has now been outdated by the Upstart and initd programs in most Linux Distros. It is still maintained for backwards compatibility.
Within the /etc directory are several folders labeled "rc0.d, rc1.d" etc, through rc6.d. These are the directories the kernel refers to to know which init scripts it should run for that runlevel. They are symbolic links to the system service scripts residing in the /etc/init.d directory.
In the context you are using it, it would appear that you are listing any files with rc in the name. The code in these files will set the way the services/tasks startup and run when initialized.

determine if clang-format finds .clang-format file (in a shell or cmake script)

what i want to achieve
I want to pack a .clang-format file with my software, which only gets used if the user doesn't provide their own.
My idea so far is to use clang-format -style=file which will find the users .clang-format if it is "located in one of the parent directories of the source file". (Which might be the case because it is in their home directory, or because they are using my package as a git submodule, or because they manually placed it after downloading my software).
If no .clang-format file is found, then the one shipped with my software should be used - e.g. by symlinking to mypackage/auxiliary_files/.clang-format in the top level. I want to do this somewhat automatized from cmake directly or by calling a shell script from cmake (or other).
workflow in short
clang-format finds .clang-format: do nothing (as shell script exit 0; as cmake script set(I-FOUND-CLANG-FORMAT 1) or something similar)
clang-format doesn't find .clang-format: call ln -s auxiliary_files/.clang-format
what I don't want to do
I don't want to write a loop which replicates the search behaviour of clang-format (going one directory up to look for .clang-format until either it's found or the top most directory is reached) to have built-in 100% compatibility.
options i've seen but didn't figure out how to use for my goal
clang-format does not appear to return a non-zero status code if no style file has been provided although style=file is set, even if -fallback-style=none is set. I also don't see in the printout if the fallback option or the regular option is used.

How to make CMake reconfiguration depend on custom file?

I have a project under CMake with some files generated with python generator from XML files. I cannot specify all files generated by this generator in CMakeLists.txt so I use file globbing for this.
The problem is that when I update my XML files or generator sources (which are in the same repository) I would like to have my build system reconfigured so changed files are taken into account when rebuilding the code (via make for example).
Is it possible to make CMake treat some files like it treats CMakeLists.txt files and to make it regenerate build system when those file are changed?
It doesn't require any kind of workarounds. The standard way is to use CMAKE_CONFIGURE_DEPENDS property:
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS <filename>)
Yes, you should be able to do that by (ab)using configure_file(). Configuring a file makes the source a dependency of the CMake run, so that any changes in it cause a reconfiguration. Simply like this:
configure_file(MyInputFile.xml DummyOutput.xml)
Since it has been a while I will add to #roolebo's answer.
There's actually a better command to add a dependency on a file:
set_directory_properties(PROPERTIES CMAKE_CONFIGURE_DEPENDS <relative_or_full_path_to_file>)
What might be confusing is that this command adds a property to the current directory. Well, it does not matter since you can set a full path to a file that resides outside of the current directory's scope, for instance: ../../config.json

How to install a FindXXX.cmake to a correct location?

I am developing a library which uses CMake to control it. It would be good to provide a "FindXXX.cmake" which locates the library and header files. This file would enable the users to use the command "find_package(XXX)" to find my library.
However, I don't know how to install my lib's "FindXXX.cmake" to an correct location. I failed to find a CMake's build-in mechanism to install a "FindXXX.cmake". In addition, CMake's variable "CMAKE_MODULE_PATH" is a list of directories, so I cannot install according to that vairable because I cannot decide which specific directory to use.
If the copy of CMake is installed to a standard location(i.e. use no prefix etc) then this can be done by placing the file in /usr/share/cmake/Modules/ directory.
If you are going to supply a bundle probably you can add some commands to check if the cmake is available. if yes you can check for cmake --system-information|grep _INCLUDED_SYSTEM_INFO_FILE value from that to get modules directory.
Otherwise there's no way you can do that.
A workaround can be done i.e. if there is a binary in your bundle then you can add a command line option for placing this file.

How to specify output folder for self-extracting ZIP file

extracting ZIP files that have been created using:
PKSFX(R) Version 2.50 FAST! Self Extract Utility for Windows 95/NT 4-15-1998
Is there an option to specify which folder the files contained in the EXE should be extracted to?
By typing "/help" I was able to find some useful options (like Overwrite, Exclude, etc.), but I cannot see anything related to the Output Folder.
Any suggestion?
Thank you!
I found the following over at ousob.com. It appears as part of a larger article which seems to have the documentation for the whole PKSFX suite. It looks like you run the executable and then specify any flags followed by the path to extract to and, optionally, specific named files from within the archive to be extracted if you don't want them all.
PKSFX Command Summary
Command line syntax and options are the same as PKUNZIP. The options
listed below are offered by a self-extracting file.
Syntax: pksfx [option] [d:\path] [file]* [file]*
PKSFX indicates the name of the self-extracting file you are executing.
No options are necessary if you wish to simply extract all files to the
current directory. If you wish to extract the contents to another
directory, indicate the drive and/or path the files should extract to. To
extract only particular files, indicate the name(s) at the end of the
command line.
Options:
#listfile.lst Specify list of files for extraction*
-c[m] Extract to console*
-d Re-create directories stored in .ZIP file*
-l Display software license agreement*
-n Extract only newer files*
-o Overwrite existing files
-p[a|b][c][#] Extract to printer*
-s<password> Decrypt with password*
-t Test file integrity*
* Indicates options not available in the PKSFX Junior and PKUNZIP Junior
programs.
Options should be placed after the self-extracting files name. If
multiple options are used they must be separated by a space and each must
have its own option indicator (either - or /).
All options behave in the same manner as they do with PKUNZIP, with one
exception. The -s option cannot accept keyboard entry. A password
entered with a self-extracting file must be able to be entered from the
command line.