I want to distribute Chromium I just compiled. The problem is, just after compiling, the directory with the binary weights over 39GB!
How can I filter only needed for operation files? I think it should be at most about 1GB.
I am on Windows, and followed instructions from here: https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md
The directory in question looks like this: several subdirectories, and ~1400 single files in root.
Ideally I'm looking for specific guidline, including files and folders I must keep.
You have to distribute mini installer only which will be in your build folder as mini_installer.exe. You can build mini installer by executing the following command:
ninja -C out\YourBuildFolder mini_installer
Basically mini installer is just a packer which packs the following files:
setup.exe
chrome.packed.7z
More information on it can be found here. So executing mini installer will extract those files and execute setup.exe, which will then install your Chromium fork. Also, for distributing your fork, you should build release versions which you can specify when you run this command:
gn args out\YourBuildFolder
Basically it will open args.gn file located in out\YourBuildFolder and then you set:
is_debug = false
You might need those files and folders for debugging your Chromium fork as it includes the debug symbols, which are required for debugging.
Related
There is no useful information on the site describing how to install the file .I have tried extracting the .tar file, installing through command prompt . there is no information available on the web.OS used is windows 11. Its for a project to extract data from images, using OCR. Poppler is used for getting page numbers of the pdf file which will be converted to an image file later in the process."https://poppler.freedesktop.org/" is the site from which I downloaded the file.Is this the right site.Any answer is helpful.Thank you
Poppler source is constantly updated, and thus common for Linux and Mac users to build or brew on demand. It is not much different when using Programming Suites like Python, Ruby etc.
Windows users expect one exe, but the poppler utils were built as a spin off from non-commercial licensed xpdf and for personal 32 bit users that is often simpler.
I have given examples for how simple that xpdf unpacking can be for one exe in several posts such as https://stackoverflow.com/a/68697144/10802527 (how to scan a file list, not used here) and https://stackoverflow.com/a/73123537/10802527 (how to use to run a single file) and
https://stackoverflow.com/a/73437398/10802527 (running one exe on demand)
Poppler prebuilt binaries are available as 64bit only so the first step after making a work directory is download latest version from https://github.com/oschwartz10612/poppler-windows using most current
https://github.com/oschwartz10612/poppler-windows/releases/download/v22.04.0-0/Release-22.04.0-0.zip and save to the working folder, then you can use right click Extract All... OR
tar -m -xf Release-22.04.0-0.zip to unpack in that folder so it should look like in the binary folder
Now the exe files are in a subdirectory and when using those it is best if that folder is included on the path environment.
RESIST any means to add using set or worse setx simply add folder via system gui, note in some cases after saving the setting it may need log off and log on to stick and in very rare cases even a reboot/restart.
I'm trying to create a CPack-based MacOS installer for an audio plugin project. The default location of MacOS audio plugin is in the /Library/Audio/PlugIns/ folder which needs root rights to be written to.
AFAIK CPack takes the destination path for the installed artifacts from the path specified in the CMake INSTALL command, so my CMakeLists.txt looks like that:
# CPack takes these paths as the locations where the plugins should be installed in the end
install (TARGETS MYPLUGIN_VST3 LIBRARY DESTINATION /Library/Audio/Plug-Ins/VST3 COMPONENT VST3)
install (TARGETS MYPLUGIN_AU LIBRARY DESTINATION /Library/Audio/Plug-Ins/Components COMPONENT AU)
# This makes sure that only the two components and nothing else is part of our installer
SET (CPACK_COMPONENTS_ALL VST3 AU)
# We want to use the native Apple GUI installer
SET (CPACK_GENERATOR productbuild)
Now, when I call cpack to build the installer it fails because of a permission issue as it installs the plugins as a first step before building the installer. The only solution I found was running cpack with root rights to let it write to these locations during the install step which seems like bad practice to me and might be even worse when trying to run this on a build server in future. As I don't need the install step but only want the resulting installer, I wonder if there is any way to avoid the install step and let CPack grab the files to wrap into the installer directly from the binary directory where they were placed after build. Didn't find anything regarding that in the documentations, but I'm just starting with CMake and CPack, so I might overlook something obvious here
I am building an installer using InstallForge.
Along with my install, i need to run some Third Party installers, for example, Cuda 9.1.
What I want is to create an installer, and a folder structure like this:
Installer.exe
InstallsDir
-Cuda.exe
-ThirdpartyInstall.exe
Then when my installer runs, it should also run the other two exe files.
In the setup process for InstallForge, it allows you to run commands, which i can use to run the exe files.
There is a command variable: <installpath>\ that is used to run a file from the path that my programme is installed to.
My question is, is there a similar command that i can use to run a file in the directory that the installer runs from?
How can i set a relative link to the current directory using InstallForge setup?
I'm having a problem deploying an update of my app to the store.
The app runs SQLite, and I've recently discovered it throws an error on certain x64 architectures.
BadImageFormatException: An attempt was made to load a program with an
incorrect format.
I understand what this means. The x64 version of the app is using the x86 compiled version of sqlite3.dll. I can get around this issue and build an x64 version by the following method.
Open Project > Properties, and set Platform and Platform Target to x64.
Save
Open Build > Configuration Manager and set Active Platform and Platform (Release) to x64.
Build the project
Open Project > Store > Create App Packages and generate my package
This creates a correct x64 app package with the x64 version of sqlite3.dll
Following this for all three architectures (x86, x64 and ARM) gives me three separate appxbundle files. When I go to upload a new package to the store through the developer dashboard, I can only upload one of these.
If I open "Create App Packages" and choose all three architectures for my bundle, it generates a single appxbundle for all three. However when I unzip this appxbundle I can see that the x64 build is using the x86 compiled sqlite3.dll and not the x64 version.
I tried opening the appxbundle in 7zip and replacing the files, but 7zip could not write to the file, only read it.
I then tried unzipping the appxbundle and replacing each of the three builds with the correct builds from the singular appxbundles. I then zipped the lot together using no compression and renamed .zip to .appxbundle, but the store rejected this as an invalid file.
I'm guessing there's some kind of signing going on or a proprietary compression. To be honest I didn't expect that to work but it was worth a try.
How do I build the correct version of my app for each architecture and include it in a single appxbundle? Can I manually create my own appxbundle from separate builds?
SOLUTION
I have accepted crea7or's answer below, but I just wanted to expand on it a little
Using the MakeAppX.exe command line tool I was able to unbundle and rebundle my appxbundle file correctly, using the following command
// to unbundle
MakeAppX.exe unbundle /p MyPackage.appxbundle /d MyPackage
// to bundle
MakeAppX.exe bundle /d MyPackage /p MyPackage.appxbundle
A couple of handy pointers. Make sure you use the 8.1 version of MakeAppX, as the 8.0 version cannot bundle or unbundle.
C:\Program Files (x86)\Windows Kits\8.1\bin\x86\makeappx.exe
You'll save yourself a lot of hassle and typing if you simply add this path to your PATH Environment Variables in Advanced system settings. That way you can run MakeAppX from any location. This might seem obvious to people of my generation but not everyone is so familiar with DOS. =)
Visual Studio creates .appxupload packages, which according to this question, are zip files renamed as .appxupload. MakeAppX cannot create or unbundle .appxupload packages - you have to use a zip app.
However, any .appxupload package I created with 7zip did not validate when uploaded. Luckily it seems that the store will accept the .appxbundle directly, so I didn't need to zip it up at all, only bundle it. I've submitted this to the store. I'll report back if it gets approved.
update
the above appxbundle file was not approved, failed technical tests. I tried the zip approach again and it was accepted this time, again I'll report back if this passes.
To sum up:
c:\MyApp.appxupload -> [unzip] -> c:\MyApp\
c:\MyApp\MyApp.appxbundle -> [makeappx unbundle] -> c:\MyApp\MyApp\
c:\MyApp\MyApp\MyApp.appx -> [do whatever you need to here]
c:\MyApp\MyApp\ -> [makeappx bundle] -> c:\MyApp\MyApp.appxbundle
c:\MyApp\ -> [zip] -> c:\MyApp.zip
c:\MyApp.zip -> [rename] -> c:\MyApp.appxupload
You should use MakeAppx tool to create valid appx package bundle, because they are signed. Here is the tutorial about creating bundles.
I can't find any information on how to install Qt built on Windows.
In wiki article How to set up shadow builds on Mac and Linux there's description of -prefix option in configure script but this option is not available on Windows.
I know I can use Qt right from the build folder but it does not seem the right thing not to perform an install step. One problem with this approach is size; Qt's build folder takes about 4GB space whereas after installing using binary installer Qt takes about 1GB space. I guess the difference is due to temporary files created during building. I hope some install procedure would install (copy) only needed files leaving temporary files in the build folder.
As İsmail said there's no install step for Qt on Windows.
However one can try to approximate it by performing the following operations.
Cleaning
Run make clean in the build folder to remove all temporary files.
Moving
Copy build folder to the place where you want Qt "installed". Let's call it INSTALL_DIR.
Fixing paths hardcoded in the qmake.exe executable
Run qmake -query to see what paths are compiled (hardcoded) into qmake and
a. Fix paths containing the build folder by replacing it with the INSTALL_DIR using qmake -set (1).
or
b. Create a qt.conf file in the bin subfolder of the INSTALL_DIR specifing new Qt paths inside it.
Adding current directory to include path
In Qt's provided binary distributions, the pwd is included in the QMAKE_INCDIR and thus ends up in your projects include path as ".". This does not happen by default in a custom built Qt, so you have to add the following line to mkspecs/YOUR-PLATFORM-HERE/qmake.conf file:
QMAKE_INCDIR += "."
Fixing prl files
When you add a Qt component to a project file (such as CONFIG += uitools), Qt looks in %QTDIR%/lib/QtUiTools.prl to find the library dependencies of that component. These files will have the hard coded path of the directory in which Qt was configured and built. You have to replace that build directory with the one to which you moved Qt for all lib/*.prl files.
Making source available
If you made a shadow build (build made inside folder other than the one containg sources), headers in the include subfolder only forward to the original headers. For example; BUILD_DIR\include\QtCore\qabstractanimation.h looks like this
#include "SRC_DIR/src/corelib/animation/qabstractanimation.h"
If you don't want to depend on the existence of the folder containg sources you have to copy SRC_DIR/src subfolder to your destination folder and fix all headers in the include folder so that they forward to the new location of src subfolder.
The bottom line:
The build process of Qt under Windows makes it really akward to move (install) Qt after building. You should do this only if ... well I can't find any good reason to go through all this trouble.
Remember
The easy way is to place Qt's sources in the folder where you want Qt to stay after building and make a build in this folder. This makes all steps but 1 and 4 above unnecessary.
1)
The variables you set with qmake -set are saved in the registry key
HKEY_CURRENT_USER\Software\Trolltech\QMake\<QMAKE_VERSION>.
Because of this you might have a problem when you would like to have different projects using different versions of Qt which happen to have the same version of qmake. In this case the better solution is to use qt.conf file (actually files as you need one file for each Qt installation) (option 3b).
Many of the information above come from the RelocationTricks wiki page authored by Gabe Rudy. Check out his Qt (Qt4) Opensource Windows Installers of Pre-built Binaries with MSVC 2008 project which gives you easy solution of above problems.
This answer is a replacement for steps 3 and 5 of Piotr's (currently top rated) answer above, but you may still need the other steps in his answer, depending what you're trying to achieve.
This is the operation which the official installer uses to fix the hardcoded paths during the installation: qt.520.win32_msvc2012.addons/meta/installscript.qs
This is how the operation is implemented: qtpatchoperation.cpp
This is the list of files that it fixes: files-to-patch-windows-qt5
And this shows how to invoke an installer operation as a standalone command from the commandline: Operations (Qt Installer Framework Manual)
To summarize: after moving your Qt directory to where you want it, download any one of the official Qt installers and run it with the following commandline arguments:
cd <path>
installer.exe --runoperation QtPatch windows <path> qt5
Replace <path> with the full path of your Qt directory after you moved it (the qtbase directory if you are using Qt 5). Omit the final qt5 argument if you are using Qt 4.
This will fix the hardcoded paths in qmake.exe, .prl files, and others. It gives you the exact same behaviour that the official installers have in that respect.
For the initial move, nmake "INSTALL_ROOT=\somewhere" install works for me. So that's steps 1 and 2 of Piotr's answer covered. And I haven't needed steps 4 or 6, FWIW.
I can configure QT 5 on WINDOWS (Visual Studio build) with the prefix option like:
configure -prefix C:\the\path\I\want ...
then call:
nmake
nmake install
and the latter will install Qt in C:\the\path\I\want.
I did it without problems with Qt 5.2.1 and 5.3.x, so far. So, any earlier problems seem to be fixed by now.
It's very odd people claim that there is no "make install" on Windows.
I have used it many times, and I agree that it's not what it is on other platforms, but it serves its purpose.
How I use Qt's make install on Windows (from cmd):
configure
(n/mingw32-)make
(n/mingw32-)make docs
(n/mingw32-)make install
The make install bit copies all necessary headers to be able to delete your source directory. Delete all objects and unecessary stuff:
del /S /Q *.obj lib\*.dll
rmdir /S /Q docs-build qmake tools src
This allows you to remove the source directory. I don't know what impact this has on debugging Qt source code, but it sure reduces the size of a shadow build. I use it to maintain 32 and 64 bit builds with minimal size.
Qt on Windows is not installable with make install, you will notice that Qt installer for Windows just patches dlls & pdbs for the new install location.
What I would suggest is to do a shadow build in the place you would like to install it. You can manually remove *.obj files to save up space.
Qt's own build instructions show how this is done, by search/replace within each Makefile. Assuming the source was extracted to C:\qt-4.8.3 and build was performed within that directory, then do this:
fart -c -i -r Makefile* $(INSTALL_ROOT)\qt-4.8.3 $(INSTALL_ROOT)\my-install-dir
set INSTALL_ROOT=
mingw32-make install
Then create a config file that tells qmake about its new installation path. Create a textfile C:\my-install-dir\bin\qt.conf:
[Paths]
Prefix=C:/my-install-dir
Translations = translations
Then as a final step (as Randy kindly pointed out) you need to patch qmake.exe, which can be done using a simple utility called QtMove. This same tool also automatically updates all the prl files.
Step 1: Move Qt
Cut and Paste
Current directory - C:\tools\Qt
Destination directory -C:\sim\dep\Qt
Step 2: Get Old Qt Directory
Go to C:\sim\dep\Qt\2010.02.1\Qt
Open .qmake.cache
Find variable QT_SOURCE_TREE
Note the value of QT_SOURCE_TREE
Mine was C:\tools\Qt\2010.02.1\Qt
Step 3: Patch Qt
Go to C:\sim\dep\Qt\2010.02.1\bin
The syntax is qpatch.exe list oldDir newDir
qpatch.exe files-to-patch-windows C:\tools\Qt\2010.02.1\Qt C:\sim\dep\Qt\2010.02.1\Qt
Step 4: Set Environment Variables
set QTDIR=C:\sim\dep\Qt\2010.02.1\Qt
set QMAKESPEC=C:\sim\dep\Qt\2010.02.1\Qt\mkspecs\win32-g++
set PATH=%path%;C:\sim\dep\Qt\2010.02.1\Qt\bin
set PATH=%path%;C:\sim\dep\Qt\2010.02.1\bin
You can do all of this with a batch file. This took me a fair while to work out and it has saved me a lot of time since. It's a script to automatically update a Qt installation to new locations. The batch file is available here.
There is a simple utility QtMove (http://www.runfastsoft.com) can do this easily.
Runs the relocated qmake.exe build your .pro file and everything should be linked with new Qt libs.