mirror of https://github.com/GNOME/gimp.git
![]() From now, Windows contributors can use the default shell provided by the OS (which is PS since Windows build 10.0.14971.0), like Linux and macOS users do. We still use MSYS2 but not the POSIX shell. This change adds these features: '1_build-deps-msys2.sh' is now '1_build-deps-msys2.ps1' - Faster clonning by using 'git-scm' (the MSYS2 one had performance problems) - Easier to use non-MSYS2 binaries, not only 'git-scm' but also official meson, deps from vckpg etc. This is a needed step towards the future use of MSVC. '2_build-gimp-msys2.sh' is now '2_build-gimp-msys2.ps1' - By default, vanilla builds (normally triggered on PS) will create a bundle, dropping the need of 'gimp.cmd' (that adressed .typelib and .interp limits), which is inline with other (Cmake-based) projects like Darktable and Inkscape. This change is important because even Windows devs more experienced than me get confused with the relocatibility stuff, which is the default on Windows. '2_bundle-gimp-uni_base.sh' - As a result of the change above, bundling code was changed to be a bit faster. It still is, however, painfully slow, since meson doesn't have a 'install()' function like Cmake to prepend targets in Ninja's 'install_manifest.txt'. Since we are not using a POSIX shell (nor 'mintty') anymore: - GIMP can be built from every path easily with R. Click "Open Terminal", with IDE integrations etc, without needing to manual tweak MSYS2 .ini files etc. We could tweak MSYS2 to get the features above but not top-tier integration. - Developers can be more aware of Windows native vars, paths etc, and avoid bugs Some build files were improved to support the 'Windows way of doing things'. - No need to close and reopen terminal anymore after running 'pacman -Suy'! --- REGRESSION: Vala plug-ins are temporarely gone due to 'vapigen' bugs, a small regression since this is a gnomeish language but I will investigate how to fix. |
||
---|---|---|
.. | ||
groups | ||
README | ||
README_NEW_PDB_PROC | ||
app.pl | ||
enumcode.pl | ||
enumgen.pl | ||
enums-external.pl | ||
enums.pl | ||
groups.pl | ||
lib.pl | ||
meson-enumcode.sh | ||
meson-enumgen.sh | ||
meson-pdbgen.sh | ||
meson.build | ||
pdb.pl | ||
pdbgen.pl | ||
stddefs.pdb | ||
util.pl |
README
Some mostly unfinished docs are here. -Yosh This document describes the tool PDBGEN. If you added or modified .pdb files do not run this tool manually but run make instead! It will call pdbgen.pl then to generate the files into the right output directories. PDBGEN ------------------ What is this? PDBGEN is a tool to automate much of the drudge work of making PDB interfaces to GIMP internals. Right now, it generates PDB description records, argument marshallers (with sanity checking) for the app side, as well as libgimp wrappers for C plugins. It's written so that extending it to provide support for CORBA and other languages suited to static autogeneration. Invoking PDBGEN from the command line: 1. Change into the ./pdb directory. 2. $ ./pdbgen.pl DIRNAME where DIRNAME is either "lib" or "app", depending on which set of files you want to generate. The files are written into $destdir/app or $destdir/libgimp. $destdir is the environment variable destdir. If it's not set, then it's the ./pdb directory. Make sure the directories $destdir/app and $destdir/libgimp already exist and you have write permissions. Otherwise the code generator will fail and exit. It's up to you to diff the file you changed. When you're happy with the generated file, copy it into the actual ./app/ or ./libgimp/ directory where it finally gets built. Anatomy of a PDB descriptor: PDB descriptors are Perl code. You define a subroutine, which corresponds to the PDB function you want to create. You then fill certain special variables to fully describe all the information pdbgen needs to generate code. Since it's perl, you can do practically whatever perl lets you do to help you do this. However, at the simplest level, you don't need to know perl at all to make PDB descriptors. Annotated description: For example, we will look at gimp_display_new, specified in gdisplay.pdb. sub display_new { We start with the name of our PDB function (not including the "gimp_" prefix). $blurb = 'Create a new display for the specified image.'; This directly corresponds to the "blurb" field in the ProcRecord. $help = <<'HELP'; Creates a new display for the specified image. If the image already has a display, another is added. Multiple displays are handled transparently by the GIMP. The newly created display is returned and can be subsequently destroyed with a call to 'gimp-display-delete'. This procedure only makes sense for use with the GIMP UI. HELP This is the help field. Notice because it is a long string, we used HERE document syntax to split it over multiple lines. Any extra whitespace in $blurb or $help, including newlines, is automatically stripped, so you don't have to worry about that. &std_pdb_misc; This is the "author", "copyright", and "date" fields. Since S&P are quite common, they get a special shortcut which fills these in for you. Stuff like this is defined in stddefs.pdb. @inargs = ( &std_image_arg ); You specify arguments in a list. Again, your basic image is very common, so it gets a shortcut. @outargs = ( { name => 'display', type => 'display', desc => 'The new display', alias => 'gdisp', init => 1 } ); This is a real argument. It has a name, type, description at a minimum. "alias" lets you use the alias name in your invoker code, but the real name is still shown in the ProcRecord. This is useful not only as a shorthand, but for grabbing variables defined somewhere else (or constants), in conjunction with the "no_declare" flag. "init" simply says initialize this variable to a dummy value (in this case to placate gcc warnings) %invoke = ( headers => [ qw("gdisplay.h") ], These are the headers needed for the functions you call. vars => [ 'guint scale = 0x101' ], Extra variables can be put here for your invoker. code => <<'CODE' { if (gimage->layers == NULL) success = FALSE; else success = ((gdisp = gdisplay_new (gimage, scale)) != NULL); } CODE The actual invoker code. Since it's a multiline block, we put curly braces in the beginning.