From 025847c86f22d68197aa90429668dfe8e4d97b86 Mon Sep 17 00:00:00 2001 From: sqwlly Date: Wed, 14 Jun 2023 11:52:05 +0800 Subject: [PATCH 1/2] =?UTF-8?q?OAT=E6=95=B4=E6=94=B9=20Signed-off-by:=20s3?= =?UTF-8?q?0029175=20?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: sqwlly Change-Id: I9ac6fd98ef3de8289346d2dcce7ce20ad5398bf8 --- CONTRIBUTING.md | 274 +++++++++++++++++++++++++++++++++++++++++++++++ OAT.xml | 22 +++- README | 1 + README.md | 49 +++++++++ README.rationale | 10 ++ README.win32 | 1 + README.win32.md | 233 ++++++++++++++++++++++++++++++++++++++++ install.sh | 2 + 8 files changed, 589 insertions(+), 3 deletions(-) create mode 100644 CONTRIBUTING.md create mode 100644 README create mode 100644 README.md create mode 100644 README.rationale create mode 100644 README.win32 create mode 100644 README.win32.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..52f17b1 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,274 @@ +# Contribution guidelines + +Thank you for considering contributing to the GLib project! + +These guidelines are meant for new contributors, regardless of their level +of proficiency; following them allows the core developers of the GLib project to +more effectively evaluate your contribution, and provide prompt feedback to +you. Additionally, by following these guidelines you clearly communicate +that you respect the time and effort that the people developing GLib put into +managing the project. + +GLib is a complex free software utility library, and it would not exist without +contributions from the free and open source software community. There are +many things that we value: + + - bug reporting and fixing + - documentation and examples + - tests + - testing and support for other platforms + - new features + +Please, do not use the issue tracker for support questions. If you have +questions on how to use GLib effectively, you can use: + + - the `#gtk` IRC channel on irc.gnome.org + - the [`glib` tag on GNOME's Discourse](https://discourse.gnome.org/tags/glib) + +You can also look at the [`glib` tag on Stack +Overflow](https://stackoverflow.com/questions/tagged/glib). + +The issue tracker is meant to be used for actionable issues only. + +## How to report bugs + +### Security issues + +You should not open a new issue for security related questions. + +When in doubt, send an email to the [security](mailto:security@gnome.org) +mailing list. + +### Bug reports + +If you’re reporting a bug make sure to list: + + 0. which version of GLib are you using? + 0. which operating system are you using? + 0. the necessary steps to reproduce the issue + 0. the expected outcome + 0. a description of the behavior + 0. a small, self-contained example exhibiting the behavior + +If the issue includes a crash, you should also include: + + 0. the eventual warnings printed on the terminal + 0. a backtrace, obtained with tools such as GDB or LLDB + +If the issue includes a memory leak, you should also include: + + 0. a log of definite leaks from a tool such as [valgrind’s + memcheck](http://valgrind.org/docs/manual/mc-manual.html) + +For small issues, such as: + + - spelling/grammar fixes in the documentation, + - typo correction, + - comment clean ups, + - changes to metadata files (CI, `.gitignore`), + - build system changes, or + - source tree clean ups and reorganizations; + +or for self-contained bug fixes where you have implemented and tested a solution +already, you should directly open a merge request instead of filing a new issue. + +### Features and enhancements + +Feature discussion can be open ended and require high bandwidth channels; if +you are proposing a new feature on the issue tracker, make sure to make +an actionable proposal, and list: + + 0. what you’re trying to achieve and the problem it solves + 0. three (or more) existing pieces of software which would benefit from the + new feature + 0. how the feature is implementable on platforms other than Linux + +New APIs, in particular, should follow the ‘rule of three’, where there should +be three (or more) pieces of software which are ready to use the new APIs. This +allows us to check that the new APIs are usable in real-life code, and fit well +with related APIs. This reduces the chances of awkward or unusable APIs becoming +stable in GLib and having to be supported forever. + +A common way to introduce new APIs or data types to GLib is to prototype them in +another code base for a while, to gain real-life experience with them before +they are imported into GLib and marked as stable. + +Each feature should also come fully documented, and with tests which approach +full branch coverage of the new code. GLib’s CI system generates code coverage +reports which are viewable for each merge request. + +If proposing a large feature or change, it’s better to discuss it (on the +`#gtk` IRC channel or on [Discourse](https://discourse.gnome.org) before +putting time into writing an actionable issue — and certainly before putting +time into writing a merge request. + +## Your first contribution + +### Prerequisites + +If you want to contribute to the GLib project, you will need to have the +development tools appropriate for your operating system, including: + + - Python 3.x + - Meson + - Ninja + - Gettext (19.7 or newer) + - a [C99 compatible compiler](https://wiki.gnome.org/Projects/GLib/CompilerRequirements) + +Up-to-date instructions about developing GNOME applications and libraries +can be found on [the GNOME Developer Center](https://developer.gnome.org). + +The [GLib project uses GitLab](https://gitlab.gnome.org/GNOME/glib/) for code +hosting and for tracking issues. More information about using GitLab can be +found [on the GNOME wiki](https://wiki.gnome.org/GitLab). + +### Getting started + +You should start by forking the GLib repository from the GitLab web UI, and +cloning from your fork: + +```sh +$ git clone https://gitlab.gnome.org/yourusername/glib.git +$ cd glib +``` + +**Note**: if you plan to push changes to back to the main repository and +have a GNOME account, you can skip the fork, and use the following instead: + +```sh +$ git clone git@gitlab.gnome.org:GNOME/glib.git +$ cd glib +``` + +To compile the Git version of GLib on your system, you will need to +configure your build using Meson: + +```sh +$ meson _builddir . +$ cd _builddir +$ ninja +``` + +Typically, you should work on your own branch: + +```sh +$ git checkout -b your-branch +``` + +Once you’ve finished working on the bug fix or feature, push the branch +to the Git repository and open a new merge request, to let the GLib +core developers review your contribution. + +### Code reviews + +Each contribution is reviewed by the core developers of the GLib project. + +The [CODEOWNERS](./docs/CODEOWNERS) document contains the list of core +contributors to GLib and the areas for which they are responsible; you +should ensure to receive their review and signoff on your changes. + +It is our intention that every commit to GLib is reviewed by at least one other +person, including commits from core developers. We all make mistakes and can +always learn from each other, and code review allows that. It also reduces +[bus factor](https://en.wikipedia.org/wiki/Bus_factor) by spreading knowledge +of each commit between at least two people. + +With each code review, we intend to: + + 0. Identify if this is a desirable change or new feature. Ideally for larger + features this will have been discussed (in an issue, on IRC, or on Discourse) + already, so that effort isn’t wasted on putting together merge requests + which will be rejected. + 0. Check the design of any new API. + 0. Provide realistic estimates of how long a review might take, if it can’t + happen immediately. + 0. Ensure that all significant contributions of new code, or bug fixes, are + adequately tested, either through requiring tests to be submitted at the + same time, or as a follow-up. + 0. Ensure that all new APIs are documented and have [introspection + annotations](https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations). + 0. Check that the contribution is split into logically separate commits, each + with a good commit message. + 0. Encourage further high quality contributions. + 0. Ensure code style and quality is upheld. + +If a code review is stalled (due to not receiving comments for two or more +weeks; or due to a technical disagreement), please ping another GLib core +developer on the merge request, or on IRC, to ask for a second opinion. + +### Commit messages + +The expected format for git commit messages is as follows: + +```plain +Short explanation of the commit + +Longer explanation explaining exactly what’s changed, whether any +external or private interfaces changed, what bugs were fixed (with bug +tracker reference if applicable) and so forth. Be concise but not too +brief. + +Closes #1234 +``` + + - Always add a brief description of the commit to the _first_ line of + the commit and terminate by two newlines (it will work without the + second newline, but that is not nice for the interfaces). + + - First line (the brief description) must only be one sentence and + should start with a capital letter unless it starts with a lowercase + symbol or identifier. Don’t use a trailing period either. Don’t exceed + 72 characters. + + - The main description (the body) is normal prose and should use normal + punctuation and capital letters where appropriate. Consider the commit + message as an email sent to the developers (or yourself, six months + down the line) detailing **why** you changed something. There’s no need + to specify the **how**: the changes can be inlined. + + - When committing code on behalf of others use the `--author` option, e.g. + `git commit -a --author "Joe Coder "` and `--signoff`. + + - If your commit is addressing an issue, use the + [GitLab syntax](https://docs.gitlab.com/ce/user/project/issues/automatic_issue_closing.html) + to automatically close the issue when merging the commit with the upstream + repository: + +```plain +Closes #1234 +Fixes #1234 +Closes: https://gitlab.gnome.org/GNOME/glib/issues/1234 +``` + + - If you have a merge request with multiple commits and none of them + completely fixes an issue, you should add a reference to the issue in + the commit message, e.g. `Bug: #1234`, and use the automatic issue + closing syntax in the description of the merge request. + +### Merge access to the GLib repository + +GLib is part of the GNOME infrastructure. At the current time, any +person with write access to the GNOME repository can merge merge requests to +GLib. This is a good thing, in that it allows maintainership to be delegated +and shared as needed. However, GLib is a fairly large and complicated package +that many other things depend on, and which has platform specific behavior — so +to avoid unnecessary breakage, and to take advantage of the knowledge about GLib +that has been built up over the years, we’d like to ask people contributing to +GLib to follow a few rules: + +0. Never push to the `master` branch, or any stable branches, directly; you + should always go through a merge request, to ensure that the code is + tested on the CI infrastructure at the very least. A merge request is + also the proper place to get a comprehensive code review from the core + developers of GLib. + +0. Always get a code review, even for seemingly trivial changes. + +0. Pay attention to the CI results. Merge requests cannot be merged until the + CI passes. If they consistently fail, either something is wrong with the + change, or the CI tests need fixing — in either case, please bring this to + the attention of a core developer rather than overriding the CI. + +If you have been contributing to GLib for a while and you don’t have commit +access to the repository, you may ask to obtain it following the [GNOME account +process](https://wiki.gnome.org/AccountsTeam/NewAccounts). diff --git a/OAT.xml b/OAT.xml index a5d41ba..d58dc6f 100644 --- a/OAT.xml +++ b/OAT.xml @@ -59,14 +59,30 @@ Note:If the text contains special characters, please escape them according to th COPYING + + + + + + + + + + + - - + + + - + + + + + diff --git a/README b/README new file mode 100644 index 0000000..96dc92f --- /dev/null +++ b/README @@ -0,0 +1 @@ +See README.md diff --git a/README.md b/README.md new file mode 100644 index 0000000..9ef3b3d --- /dev/null +++ b/README.md @@ -0,0 +1,49 @@ +# GLib + +GLib is the low-level core library that forms the basis for projects such +as GTK and GNOME. It provides data structure handling for C, portability +wrappers, and interfaces for such runtime functionality as an event loop, +threads, dynamic loading, and an object system. + +The official download locations are: + + +The official web site is: + + +## Installation + +See the file '[INSTALL.in](INSTALL.in)' + +## How to report bugs + +Bugs should be reported to the GNOME issue tracking system. +(). You will need +to create an account for yourself. + +In the bug report please include: + +* Information about your system. For instance: + * What operating system and version + * For Linux, what version of the C library + * And anything else you think is relevant. +* How to reproduce the bug. + * If you can reproduce it with one of the test programs that are built + in the tests/ subdirectory, that will be most convenient. Otherwise, + please include a short test program that exhibits the behavior. + As a last resort, you can also provide a pointer to a larger piece + of software that can be downloaded. +* If the bug was a crash, the exact text that was printed out + when the crash occurred. +* Further information such as stack traces may be useful, but + is not necessary. + +## Patches + +Patches should also be submitted as merge requests to gitlab.gnome.org. If the +patch fixes an existing issue, please refer to the issue in your commit message +with the following notation (for issue 123): +Closes: #123 + +Otherwise, create a new merge request that introduces the change, filing a +separate issue is not required. diff --git a/README.rationale b/README.rationale new file mode 100644 index 0000000..85a3dfd --- /dev/null +++ b/README.rationale @@ -0,0 +1,10 @@ +This file documents various major decisions which affect GLib development, +giving a brief rationale of each decision, plus a link to further discussion. + + + * Compiler attributes: https://bugzilla.gnome.org/show_bug.cgi?id=113075#c46 + + GLib uses GIR annotations instead of compiler attributes. They are tidier, + already supported by GLib and GNOME tools, and accomplish the same task as + compiler attributes. GLib does not provide macros for attributes like + nonnull because it would not use them. diff --git a/README.win32 b/README.win32 new file mode 100644 index 0000000..2a31029 --- /dev/null +++ b/README.win32 @@ -0,0 +1 @@ +See README.win32.md diff --git a/README.win32.md b/README.win32.md new file mode 100644 index 0000000..e675522 --- /dev/null +++ b/README.win32.md @@ -0,0 +1,233 @@ +Chun-wei Fan `` +Philip Withnall `` +Nirbheek Chauhan `` + +This document was last updated in 2019. You're reading this in the future, and +lots of information might be misleading or outdated in your age. You have been +warned. + +# General + +For prebuilt binaries (DLLs and EXEs) and developer packages (headers, +import libraries) of GLib, Pango, GTK+ etc for Windows, go to +https://www.gtk.org/download/windows.php . They are for "native" +Windows meaning they use the Win32 API and Microsoft C runtime library +only. No POSIX (Unix) emulation layer like Cygwin is involved. + +To build GLib on Win32, you can use either GCC ("MinGW") or the Microsoft +Visual Studio toolchain. For the latter, Visual Studio 2015 and later are +recommended. For older Visual Studio versions, see below. + +You can also cross-compile GLib for Windows from Linux using the +cross-compiling mingw packages for your distro. + +Note that to just *use* GLib on Windows, there is no need to build it +yourself. + +On Windows setting up a correct build environment is very similar to typing +`meson; ninja` like on Linux. + +The following preprocessor macros are to be used for conditional +compilation related to Win32 in GLib-using code: + +- `G_OS_WIN32` is defined when compiling for native Win32, without + any POSIX emulation, other than to the extent provided by the + bundled Microsoft C library. + +- `G_WITH_CYGWIN` is defined if compiling for the Cygwin + environment. Note that `G_OS_WIN32` is *not* defined in that case, as + Cygwin is supposed to behave like Unix. `G_OS_UNIX` *is* defined by a GLib + for Cygwin. + +- `G_PLATFORM_WIN32` is defined when either `G_OS_WIN32` or `G_WITH_CYGWIN` + is defined. + +These macros are defined in `glibconfig.h`, and are thus available in +all source files that include ``. + +Additionally, there are the compiler-specific macros: +- `__GNUC__` is defined when using GCC or Clang +- `__clang__` is defined when using Clang or Clang-CL +- `_MSC_VER` is defined when using MSVC or Clang-CL + +`G_OS_WIN32` implies using the Microsoft C runtime, which used to be +`msvcrt.dll` and is now the [Universal CRT](https://docs.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features?view=vs-2015) +when building with Visual Studio. When using the MinGW-GCC toolchain, the CRT +in use depends on the settings used while the toolchain was built. We highly +recommend [using the Universal CRT when building with +MinGW](https://mingwpy.github.io/ucrt.html) too. + +GLib is not actively tested with the static versions of the UCRT, but if you +need to use those, patches are welcome. + +# Building software that use GLib or GTK+ + +Building software that just *uses* GLib or GTK+ also require to have +the right compiler set up the right way. If you intend to use MinGW-GCC, +follow the relevant instructions below in that case, too. + +You should link to GLib using the `-mms-bitfields` GCC flag. This flag means +that the struct layout rules are identical to those used by MSVC. This is +essential if the same DLLs are to be usable both from gcc- and MSVC-compiled +code. + +## Cross-CRT issues + +You should take care that the DLLs that your code links to are using the same +C runtime library. Not doing so can and likely will lead to panics and crashes +**unless** you're very careful while passing objects allocated by a library +linked with one CRT to a library linked to another CRT, or (more commonly) not +doing that at all. + +If you *do* pass CRT objects across CRT boundaries, do not file any issues +about whatever happens next. + +To give an example, opening a `FILE` handle created by one CRT cannot be +understood by any other CRT, and will lead to an access violation. You also +cannot allocate memory in one CRT and free it using another. + +There are [many other cases where you must not allow objects to cross CRT boundaries](https://docs.microsoft.com/en-us/cpp/c-runtime-library/potential-errors-passing-crt-objects-across-dll-boundaries?view=vs-2019), +but in theory if you're **very very** careful, you can make things work. Again, +please do not come to us for help if you choose to do this. + +# Building GLib + +You can build GLib with MinGW-GCC, MSVC, or (experimentally) with Clang-CL. + +For all compilers, you will need the following: + +- Install Python 3.6.x or newer, either 32-bit or 64-bit. We recommend enabling + the option to add it to your `PATH`. +- [Install Meson](https://mesonbuild.com/Getting-meson.html) +- Install the [Ninja build tool](https://github.com/ninja-build/ninja/releases), which can also be + installed with `pip3`. You can skip this step if you want to generate Visual + Studio project files. +- [git for Windows](https://gitforwindows.org/) is required, since Meson makes + use of git to download dependencies using subprojects. + +## Building with MinGW-GCC + +Open your MSYS or [MSYS2](https://www.msys2.org/) shell where you have the +MinGW-GCC toolchain installed, and build GLib [like any other Meson +project](https://mesonbuild.com/Quick-guide.html#compiling-a-meson-project). + +## Building with Visual Studio 2015 or newer + +Meson is now the only supported method of building GLib using Visual Studio. + +To do a build using Meson, do the following: + +- Open a Visual Studio (or SDK) command prompt that matches the Visual Studio + version and build platform (Win32/x86, x64, etc.) that will be used in all + the following steps. + +- Create an empty directory/folder for the build inside your GLib sources + directory, say, `_builddir`, and `cd` into it. + +- Set up the build using Meson: + +```cmd +> meson .. --buildtype= --prefix= [--backend=vs] +``` + + Please see [the Meson docs](https://mesonbuild.com/Builtin-options.html#core-options) + for an explanation for `--buildtype`. + + The path passed for `--prefix` need not to be on the same drive as where the + build is carried out, but it is recommended to use forward slashes for this + path. The `--backend=vs` option can be used if the Visual Studio project + generator is preferred over using Ninja. + +- Build, test and install the build: + Run `ninja` to build, `meson test` to test and `meson install` to install the + build. If you used `--backend=vs`, instead of running `ninja`, you need to + use `msbuild` or you can open the generated solution in Visual Studio. + +## Building with old versions of Visual Studio + +The steps are the same as above, with the following notes about issues that you might face. + +### C4819 build errors + +If you are building GLib-based libraries or applications, or GLib itself +and you see a `C4819` error (or warning, before `C4819` is treated as an error +in `msvc_recommended_pragmas.h`), please be advised that this error/warning should +not be disregarded, as this likely means portions of the build are not being +done correctly, as this is an issue of Visual Studio running on CJK (East Asian) +locales. This is an issue that also affects builds of other projects, such as +QT, Firefox, LibreOffice/OpenOffice, Pango and GTK, along with many other projects. + +To overcome this problem, please set your system's locale setting for non-Unicode to +English (United States), reboot, and restart the build, and the code should build +normally. + +### Support for pre-2012 Visual Studio + +This release of GLib requires at least the Windows 8.0 SDK in order to be built +successfully using Visual Studio, which means that building with Visual Studio +2008 or 2010 is possible only with a special setup and must be done in the +command line with Ninja. Please see +https://devblogs.microsoft.com/cppblog/using-the-windows-software-development-kit-sdk-for-windows-8-consumer-preview-with-visual-studio-2010/ +for references; basically, assuming that your Windows 8.0 SDK is installed in +`C:\Program Files (x86)\Windows Kits\8.0` (`$(WIN8SDKDIR)` in short), you need +to ensure the following before invoking Meson to configure the build: + +- Your `%INCLUDE%` must not include the Windows 7.0/7.1 SDK include directories, + and `$(WIN8SDKDIR)\include\um`, `$(WIN8SDKDIR)\include\um\share` and + `$(WIN8SDKDIR)\include\winrt` (in this order) must be before your stock + Visual Studio 2008/2010 header directories. If you have the DirectX SDK installed, + you should remove its include directory from your `%INCLUDE%` as well. +- You must replace the Windows 7.0/7.1 SDK library directory in `%LIB%` with the + Windows 8.0 SDK library directory, i.e. `$(WIN8SDKDIR)\lib\win8\um\[x86|x64]`. + If you have the DirectX SDK installed, you should remove its library directory + from your `%INCLUDE%` as well. +- You must replace the Windows 7.0/7.1 SDK tools directory from your `%PATH%` with + the Windows 8.0 SDK tools directory, i.e. `$(WIN8SDKDIR)\bin\[x86|x64]`. + If you have the DirectX SDK installed, you should remove its utility directory + from your `%PATH%` as well. + +The Windows 8.0 SDK headers may contain an `roapi.h` that cannot be used under plain +C, so to remedy that, change the following lines (around lines 55-57): + +``` +// RegisterActivationFactory/RevokeActivationFactory registration cookie +typedef struct {} *RO_REGISTRATION_COOKIE; +// RegisterActivationFactory/DllGetActivationFactory callback +``` + +to + +``` +// RegisterActivationFactory/RevokeActivationFactory registration cookie +#ifdef __cplusplus +typedef struct {} *RO_REGISTRATION_COOKIE; +#else +typedef struct _RO_REGISTRATION_COOKIE *RO_REGISTRATION_COOKIE; /* make this header includable in C files */ +#endif +// RegisterActivationFactory/DllGetActivationFactory callback +``` + +This follows what is done in the Windows 8.1 SDK, which contains an `roapi.h` +that is usable under plain C. Please note that you might need to copy that file +into a location that is in your `%INCLUDE%` which precedes the include path for the +Windows 8.0 SDK headers, if you do not have administrative privileges. + +### Visual Studio 2008 hacks + +- You need to run the following lines from your build directory, to embed the + manifests that are generated during the build, assuming the built binaries + are installed to `$(PREFIX)`, after a successful build/installation: + +```cmd +> for /r %f in (*.dll.manifest) do if exist $(PREFIX)\bin\%~nf mt /manifest %f (PREFIX)\bin\%~nf;2 +> for /r %f in (*.exe.manifest) do if exist $(PREFIX)\bin\%~nf mt /manifest %f (PREFIX)\bin\%~nf;1 +``` + + +- If building for amd64/x86_64/x64, sometimes the compilation of sources may seem to hang, which + is caused by an optimization issue in the 2008 x64 compiler. You need to use Task Manager to + remove all running instances of `cl.exe`, which will cause the build process to terminate. Update + the build flags of the sources that hang on compilation by changing its `"/O2"` flag to `"/O1"` + in `build.ninja`, and retry the build, where things should continue to build normally. At the + time of writing, this is needed for compiling `glib/gtestutils.c`, `gio/gsettings.c`, + `gio/gsettingsschema.c`, `glib/tests/fileutils.c` and `gio/tests/gsubprocess-testprog.c` diff --git a/install.sh b/install.sh index 3d3fc5d..ae159e1 100755 --- a/install.sh +++ b/install.sh @@ -19,6 +19,8 @@ find . ! -path "*/\.*" ! \( -name patch.tar.gz -o -name glib-2.68.1.tar.xz\ -o -name glib2.spec\ -o -name COPYING\ -o -name backport-patch.log\ + -o -name "README*"\ + -o -name CONTRIBUTING.md\ -o -name ".*" \)\ -prune -print -exec rm -rf {} \; tar -zxvf patch.tar.gz -- Gitee From a3ca4ad6dd71ace5bf26154d7bde179b4ae305b6 Mon Sep 17 00:00:00 2001 From: sqwlly Date: Wed, 14 Jun 2023 12:06:34 +0800 Subject: [PATCH 2/2] =?UTF-8?q?OAT=E6=95=B4=E6=94=B9=20Signed-off-by:=20s3?= =?UTF-8?q?0029175=20?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: sqwlly Change-Id: Ia243fd871884f0c3d544cb2a3b0c9fda567fddce --- OAT.xml | 4 ++-- install.sh | 5 ----- 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/OAT.xml b/OAT.xml index d58dc6f..e6d0c97 100644 --- a/OAT.xml +++ b/OAT.xml @@ -59,11 +59,11 @@ Note:If the text contains special characters, please escape them according to th COPYING - + - + diff --git a/install.sh b/install.sh index ae159e1..80f12d5 100755 --- a/install.sh +++ b/install.sh @@ -1,9 +1,4 @@ #!/bin/bash -# This library is free software; you can redistribute it and/or -# modify it under the terms of the GNU Lesser General Public -# License as published by the Free Software Foundation version 2.1 -# of the License. -# # Copyright(c) 2023 Huawei Device Co., Ltd. set -e -- Gitee