I am trying to switch between external and internal build via some export variable in a script. I am able to do this partially meaning for bool values but for those which take in strings how to tell buildroot to continue with default value and not prompt for values to the user.
For e.g., BR2_TOOLCHAIN_EXTERNAL_STRIP=y works fine, as it takes in bool value, but BR2_TOOLCHAIN_EXTERNAL_PATH prompts for a value, even though default is set to the correct path.
Thanks for any help
If you want to switch easily between internal and external toolchain builds, then I would suggest creating fragments of defconfig files:
One defining the internal toolchain configuration
One defining the external toolchain configuration
One defining the common options
And then, you just to :
cat internal-toolchain.config common.config > configs/myown_defconfig
make myown_defconfig
and there you are. And similarly with external-toolchain.config.
Related
Many Python tools these days are using pyproject.toml as a config file, and mirror the tool's command line arguments with config file keys. Tools may have command line flags that are not passed any arguments:
sometool --some-flag
Now, I am trying to place this --some-flag into a pyproject.toml config file and can't figure out how to have a key without any value.
[tool.sometool]
# Both of the below are invalid
some-flag
some-flag =
In TOML, is it possible to have a key without a value?
This is not possible.
It'd depend on the tool how they are doing this, so please refer to their documentation. I would guess they are treating those flags as a boolean.
[tool.sometool]
some-flag = true
I have created installer using install4j for our application.
I need to pass one argument which decides to which server profile my application should contact.
We have around 80 different profiles and we don't wish to create separate installer for each and evry server profile and would like to configure it at runtime for an exe file.
I also referred of creating response file as mentioned in install4j documentation below but even that did not help -
https://www.ej-technologies.com/resources/install4j/help/doc/installers/responseFile.html
Any idea?
There is no way to configure arguments with text files but you can define VM parameters in the .vmoptions file. If your launcher is named launcher.exe, the and the file launcher.vmoptions in the same directory contains the lines
-Dkey1=value1
-Dkey2=value2
then the system properties key1 and key2 are set to the respective values and can be queried with System.getProperty("<key name>").
Installer variables that are present in the response file are replaced automatically in .vmoptions file. If you add a .vmoptions file with the content
-Dserver=${installer:myServer}
and the installer variable myServer is defined in the installer and registered as a response file variable, you can execute System.getProperty("server") to get this value in the launcher.
I'm dealing with a .vcxproj file with the following Link segment:
<Link>
<OutputFile>$(OutDir)$(TargetName)$(TargetExt)</OutputFile>
<SuppressStartupBanner>true</SuppressStartupBanner>
<AdditionalLibraryDirectories>..\lib;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
<GenerateDebugInformation>true</GenerateDebugInformation>
<AssemblyDebug>
</AssemblyDebug>
<ProgramDatabaseFile>$(OutDir)$(TargetName).pdb</ProgramDatabaseFile>
<SubSystem>Console</SubSystem>
<RandomizedBaseAddress>false</RandomizedBaseAddress>
<DataExecutionPrevention>
</DataExecutionPrevention>
<TargetMachine>MachineX86</TargetMachine>
<ImageHasSafeExceptionHandlers>false</ImageHasSafeExceptionHandlers>
</Link>
It would seem, I should be able to add more elements to the linker's LIBPATH by simply adding one more argument to msbuild's command line: /p:AdditionalLibraryDirectories=D:\Foo\lib. Unfortunately, this seems ignored and link.exe is invoked with only the /LIBPATH:..\lib argument...
If I edit the file and replace the %(AdditionalLibraryDirectories)-part with the desired path, things work -- linker is invoked with two /LIBPATH: arguments and the executable gets built.
Why can't I specify it as property on command-line, though?
I'm using Visual Studio 2017, with msbuild announcing itself as "Build Engine version 15.9.21+g9802d43bc3".
You'll need to use a completely separate MSBuild property.
For example, on your command line:
msbuild ... /p:FooLibDir=..\lib
and in the project file:
<AdditionalLibraryDirectories>$(FooLibDir);%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
The reason that setting AdditionalLibraryDirectories on the command line doesn't work, is that the /p command line option for MSBuild sets properties, whereas AdditionalLibraryDirectories is metadata on the Link item (note how the parent of the AdditionalLibraryDirectories tag is a Link tag, not PropertyGroup).
The way to think about the difference is:
A property is a global variable accessible to everything (hence it can be set on the command line).
Metadata is specific to a single item (e.g., what additional directories to search for libs in, when linking this specific .obj).
Metadata in a ItemDefinitionGroup becomes a "template" that each instance of that item will use when declared.
When starting Netbeans, I need to add a system property named mEnvironment and set it as a sub-directory of the user's home. Example: In the netbeans.conf, I would like to add:
netbeans_default_options="-J-XX:+UseStringDeduplication -J-Xss2m -J-DmEnvironment=${USER_HOME}/mySubDirectory ......
USER_HOME is given as example of course.
Does someone know how Netbeans get the user home directory in the netbeans.conf file?
Thank you
Paul
Does someone know how Netbeans get the user home directory in the
netbeans.conf file?
The process is convoluted, and varies by operating system, but is described in great detail within netbeans.conf itself. This is the relevant content for my Apache NetBeans 11.1 installation:
# On Windows ${DEFAULT_USERDIR_ROOT} will be replaced by the launcher
# with "<AppData>\NetBeans" where <AppData> is user's
# value of "AppData" key in Windows Registry under
# "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders"
# and ${DEFAULT_CACHEDIR_ROOT} will be replaced by the launcher
# with "<Local AppData>\NetBeans\Cache" where <Local AppData> is user's
# value of "Local AppData" key in Windows Registry under
# "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders"
#
# On Mac ${DEFAULT_USERDIR_ROOT} will be replaced by the launcher
# with "~/Library/Application Support/NetBeans" and
# ${DEFAULT_CACHEDIR_ROOT} with "~/Library/Caches/NetBeans"
#
# On other systems ${DEFAULT_USERDIR_ROOT} will be replaced by the launcher
# with "~/.netbeans" and ${DEFAULT_CACHEDIR_ROOT} with "~/.cache/netbeans"
....
netbeans_default_userdir="${DEFAULT_USERDIR_ROOT}/11.1"
However, none of that really helps you, because you cannot access the values of netbeans_default_userdir or DEFAULT_USERDIR_ROOT; they are used internally by NetBeans itself, and are not System properties. You can verify this by displaying the values returned by System.getProperties(); none of the entries in netbeans.conf are shown.
Also, you can't meaningfully add new name/value pairs in netbeans.conf; you can only modify the values of the names used by NetBeans. That file is for NetBeans configuration, not user configuration. So if you add a line containing (say) MyConfSetting="ABC" then NetBeans will simply ignore that, and it won't be accessible to you either.
However, you can use an alternative approach to set a System Property for your directory in your application:
The read-only environment variable APPDATA points to your (operating system's) user directory. On my Windows 10 machine it has the value C:\Users\johndoe\AppData\Roaming.
The default user directory for NetBeans is the value of APPDATA + a sub-directory named NetBeans + a sub-directory named the NetBeans version. On my machine it is C:\Users\johndoe\AppData\Roaming\NetBeans\11.1. See the value of User directory in the Help > About screen for confirmation.
I don't know how to dynamically determine the version of NetBeans, but if that isn't important you can programmatically create a system property specifying your directory path:
String dir = System.getenv("APPDATA") + "\\NetBeans\\mySubDirectory";
System.setProperty("myDir", dir);
System.out.println("myDir=" + System.getProperty("myDir"));
On my machine that println() call displays myDir=C:\Users\johndoe\AppData\Roaming\NetBeans\mySubDirectory. I don't know if that approach meets your requirements, but I don't know of any other simple way to dynamically set your directory name.
Notes:
I checked this on Windows 10. Details may vary on other operating systems, but the overall approach should still work.
You can also specify parameters at run time using {project} > Properties > Run > Arguments (e.g. arg1=%APPDATA%\NetBeans\MyDir) and {project} > Properties > Run > VM Options (e.g. -Dvmopt1=%APPDATA%\NetBeans\MyDir), but that approach won't work because the %APPDATA% is simply treated as the literal "%APPDATA%" rather than evaluated as an environment variable.
I got the following error while starting JBoss from a command line prompt today:
'findstr' is not recognized as an internal or external command
Please google it, you can find a lot of answers. But do as below to fix it. Add the following value to Right Click My Compuer -> Advanced -> Environment Variables -> System Variables -> Select Path variable -> append the below value.
C:\WINDOWS\system32
It should work with that change.
As others pointed, issue is in wrong settings of PATH variable in Windows.
According to article this is most probably because some stupid installer wrongly modified PATH variable in Windows registry. Registry has 2 different string value types - REG_SZ and REG_EXPAND_SZ. Only the second one allows for expansion of %SystemRoot%.
So check your path by typing set path in command prompt. If you see unexpanded %SystemRoot% and other variables in Path, you are affected (PATH should show only plain directory names, not variables).
You need to edit Path variable in registry: HKEY_CURRENT_USER\Environment and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment. As it is not possible to change the type of key, save the path value somewhere, delete the key and re-create it with type REG_EXPAND_SZ. You need to logout for changes to take effect.
for me it works when I've coped findstr(from windows/system32) to wildfly/bin
Please go throught the simplest steps:-
go to C:\Windows\system32\ and copy findstr.exe file.
paste this file into the location C:\Program Files\Java\jdk1.6.0_24\bin
Run your jboss again you will get out of this.....
Check to see if you %SystemRoot% is evaluating (type set path into a command prompt, you should not see %SystemRoot%, but instead that actual path). If your path variable's (user, or systems) first entry begins with an %(an environment variable) this can cause an issue.
To resolve this, simply swap this first entry with anything else in your path that does not lead with an environment variable.
You can also hard code the directory by replacing 'findstr' with 'C:\Windows\system32\findstr'. This is useful when using systems with restricted user permissions.
I have try to work with play framework but stuck with to run activator.bat file but solution is the same just copy file from windows/system32/findsr and past it to under stuck folder then run the respective file again.
thanks to andrewsiand Suryaprakash
Please beware that current Windows systems use a Capital "S" for the System directory, so:
C:\WINDOWS\System32
%SystemRoot%\System32
Omitting the capital S will result in a neglect of the line in the %PATH%
In my case (not JBoss related) the following helped to fixed this error.
Instead of:
SET path="%path%;C:\some\additional\path"
I used:
SET "path=%path%;C:\some\additional\path"
For IBM ACE solution for
'findstr' is not recognized as an internal or external command,
Go to the path C:\Windows\System32
Find the findstr.exe, copy it and then find the path where you bin file of your application is found. eg C:\Program Files\IBM\ACE\11.0.0.12\server\bin then past it inside the bin file
cancel the console of ace and re-open it.
Then run ACE toolkit command on ace console.
Then press enter, now it can open.