doohoyi/comport
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

tips: format consistency, correct indentation for sh cmd

Browse source
This commit is contained in:
danomatika 2023-05-30 16:13:02 +02:00
parent 5c2e137f7a
commit 891fe2bafa
1 changed files with 16 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
tips-tricks.md
View file

@ -3,7 +3,7 @@ pd-lib-builder cheatsheet
# Creating special builds # Creating special builds
## building for non-native platform ## Building for non-native platform
Using pd-lib-builder >=0.6.0 we can define variable `PLATFORM` to specify a Using pd-lib-builder >=0.6.0 we can define variable `PLATFORM` to specify a
target triplet for cross-compilation. Assuming a W32 package for Pd is unzipped target triplet for cross-compilation. Assuming a W32 package for Pd is unzipped
@ -11,7 +11,7 @@ into path `${PDWIN32}`, to build for Windows 32 bit:
make PLATFORM=i686-w64-mingw32 PDDIR="${PDWIN32}" make PLATFORM=i686-w64-mingw32 PDDIR="${PDWIN32}"
#### older pd-lib-builder versions #### Older pd-lib-builder versions
Using pd-lib-builder < 0.6.0, in the absence of variable `PLATFORM`, you would Using pd-lib-builder < 0.6.0, in the absence of variable `PLATFORM`, you would
instead override variables `system`, `target.arch`, `CC` and / or `CXX`, instead override variables `system`, `target.arch`, `CC` and / or `CXX`,
@ -19,7 +19,7 @@ instead override variables `system`, `target.arch`, `CC` and / or `CXX`,
make system=Windows target.arch=i686 CC=i686-w64-mingw32-gcc STRIP=i686-w64-mingw32-strip PDDIR="${PDWIN32}" make system=Windows target.arch=i686 CC=i686-w64-mingw32-gcc STRIP=i686-w64-mingw32-strip PDDIR="${PDWIN32}"
#### toolchains #### Toolchains
To build for non-native OS and/or architecture you need a cross toolchain. On To build for non-native OS and/or architecture you need a cross toolchain. On
Linux such toolchains are relatively easy to get. For example Debian Buster Linux such toolchains are relatively easy to get. For example Debian Buster
@ -34,7 +34,7 @@ for a given platform to get the whole toolchain):
Cross toolchains for OSX/MacOS are not generally distributed. Project Cross toolchains for OSX/MacOS are not generally distributed. Project
`osxcross` from Thomas Poechtraeger can create them for Linux. `osxcross` from Thomas Poechtraeger can create them for Linux.
## building double-precision externals ## Building double-precision externals
At the time of writing (2018-02) there is no official Pd that supports At the time of writing (2018-02) there is no official Pd that supports
double-precision numbers yet. double-precision numbers yet.
@ -43,7 +43,7 @@ easily build your externals for 64-bit numbers:
make CPPFLAGS="-DPD_FLOATSIZE=64" make CPPFLAGS="-DPD_FLOATSIZE=64"
## building externals for W64 (64-bit Windows) ## Building externals for W64 (64-bit Windows)
At the time of writing (2018-02) there is no official Pd that supports At the time of writing (2018-02) there is no official Pd that supports
W64 yet. W64 yet.
@ -52,15 +52,12 @@ easily build your externals for this environment with
make CPPFLAGS="-DPD_LONGINTTYPE=__int64" CC=x86_64-w64-mingw32-gcc make CPPFLAGS="-DPD_LONGINTTYPE=__int64" CC=x86_64-w64-mingw32-gcc
To build a double-precision external for W64, use something like: To build a double-precision external for W64, use something like:
make CPPFLAGS="-DPD_LONGINTTYPE=__int64 -DPD_FLOATSIZE=64" CC=x86_64-w64-mingw32-gcc make CPPFLAGS="-DPD_LONGINTTYPE=__int64 -DPD_FLOATSIZE=64" CC=x86_64-w64-mingw32-gcc
## TODO universal binaries on OSX ## TODO universal binaries on OSX
# Project management # Project management
In general it is advised to put the `Makefile.pdlibbuilder` into a separate In general it is advised to put the `Makefile.pdlibbuilder` into a separate
@ -98,6 +95,7 @@ In short, `git subtree` is the better `git submodule`.
So here's how to do it: So here's how to do it:
#### Initial setup/check-out #### Initial setup/check-out
This will create a `pd-lib-builder/` directory containing the full history of This will create a `pd-lib-builder/` directory containing the full history of
the pd-lib-builder repository up to its release `v0.5.0` the pd-lib-builder repository up to its release `v0.5.0`
@ -109,6 +107,7 @@ This will automatically merge the `pd-lib-builder/` history into your current
branch, so everything is ready to go. branch, so everything is ready to go.
#### Cloning your repository with the subtree #### Cloning your repository with the subtree
Nothing special, really. Nothing special, really.
Just clone your repository as always: Just clone your repository as always:
@ -117,6 +116,7 @@ git clone https://git.example.org/pd/superbonk~.git
~~~ ~~~
#### Updating the subtree #### Updating the subtree
Time passes and sooner or later you will find, that there is a shiny new Time passes and sooner or later you will find, that there is a shiny new
pd-lib-builder with plenty of bugfixes and new features. pd-lib-builder with plenty of bugfixes and new features.
To update your local copy to pd-lib-builder's current `master`, simply run: To update your local copy to pd-lib-builder's current `master`, simply run:
@ -126,6 +126,7 @@ git subtree pull --prefix pd-lib-builder/ https://github.com/pure-data/pd-lib-bu
~~~ ~~~
#### Pulling the updated subtree into existing clones #### Pulling the updated subtree into existing clones
Again, nothing special. Again, nothing special.
Just pull as always: Just pull as always:
@ -133,8 +134,8 @@ Just pull as always:
git pull git pull
~~~ ~~~
#### Further reading #### Further reading
More on the power of `git subtree` can be found online More on the power of `git subtree` can be found online
- https://medium.com/@v/git-subtrees-a-tutorial-6ff568381844 - https://medium.com/@v/git-subtrees-a-tutorial-6ff568381844
- https://www.atlassian.com/blog/git/alternatives-to-git-submodule-git-subtree - https://www.atlassian.com/blog/git/alternatives-to-git-submodule-git-subtree
@ -142,8 +143,8 @@ More on the power of `git subtree` can be found online
### ~~`git submodule`~~ [DISCOURAGED] ### ~~`git submodule`~~ [DISCOURAGED]
#### Initial setup/check-out #### Initial setup/check-out
To add a new submodule to your repository, just run `git submodule add` and To add a new submodule to your repository, just run `git submodule add` and
commit the changes: commit the changes:
@ -170,6 +171,7 @@ git submodule update
~~~ ~~~
#### Updating the submodule #### Updating the submodule
Submodules are usually fixed to a given commit in their repository. Submodules are usually fixed to a given commit in their repository.
To update the `pd-lib-builder` submodule to the current `master` do something To update the `pd-lib-builder` submodule to the current `master` do something
like: like:
@ -184,6 +186,7 @@ git commit pd-lib-builder -m "Updated pd-lib-builder to current master"
~~~ ~~~
#### Pulling the updated submodule into existing clones #### Pulling the updated submodule into existing clones
After you have pushed the submodule updates in your repository, other clones of After you have pushed the submodule updates in your repository, other clones of
the repository can be updated as follows: the repository can be updated as follows:
@ -213,6 +216,7 @@ git submodule update
~~~ ~~~
#### Drawbacks #### Drawbacks
`git submodule` has a number of drawbacks: `git submodule` has a number of drawbacks:
- it requires special commands to synchronize the submodules, in addition to - it requires special commands to synchronize the submodules, in addition to
synching your repository. synching your repository.
@ -228,4 +232,3 @@ git submodule update
In general, I would suggest to **avoid** `git submodule`, and instead use the In general, I would suggest to **avoid** `git submodule`, and instead use the
better `git subtree` (above). better `git subtree` (above).