English
  • About BSPK component
  • ATL
  • BWEB
  • Version history
  • FAQ

    • Building a version

    The build screen compiles your application, builds it and prepares everything a delivery must contain. Every question is asked before starting; then the build runs to the end without interruption and logs each step. You can start it and turn to something else.

    Opening it

    Run the BSPK_BUILD method. The screen opens in its own window.

    • The project must be interpreted: an already compiled application cannot be compiled again. A compiled component is not a problem.
    • The screen detects on its own whether it is building your application or the component.
    • The build settings are 4D's (Design > Build Application). If your project has none yet, a minimal file is created: review it in that 4D dialog.
    • The output folder is the one of those settings. If it is not set, the screen asks for it; the Choose… button changes it.

    The screen

    • The version, as v<4D>.<major>.<minor> (for example v21R.16.3). The first segment follows the 4D version. The +/− buttons raise the major (the minor goes back to 0) or the minor, never below the version found at opening. Nothing is written before you click Build.
    • Create the Git version branches: offered only if your project is in a git repository, checked by default. See below.
    • Produce the ZIP archive: checked by default.
    • Notarize with Apple (macOS): on macOS only.

    At opening, the screen checks the version, the output folder and the git repository. If the version branch is already taken, it raises the minor up to the first free one and says so in yellow.

    The steps

    1. Version: the new number is written into your BSPH_VERSION_UPDATES method, on the $vl_DeliveryVersion:= (major) and $vl_InternalVersion:= (minor) lines. Everything after them on those lines is replaced: do not put a comment there.
    2. Snapshot: the content exchange snapshot is refreshed (on a development machine).
    3. Compilation, then build with 4D's settings. On failure, the log gives the likely cause.
    4. Copy of the BWEB and Resources folders into the built application. The SSL certificates (cert.pem, key.pem) are not delivered.
    5. Content: the version's content package is placed in Resources/exchange/work/content-<version>/, to be applied when the delivered version starts (see Content reconciliation). If this package cannot be produced, the build stops: no delivery without its content.
    6. Component: it is not embedded in the application (see below).
    7. Cleanup: APP_PARAMETERS, PREPROD_PARAMETERS and DEV_PARAMETERS* are removed; WEB_PARAMETERS is kept. See Parameter files.
    8. Archive: a <Application>_<version>.zip next to the application, holding the application, the update tool and its launchers (MISE-A-JOUR.cmd, UPDATE.cmd and their macOS counterparts), and a READ ME file.
    9. Git, if the box is checked.

    These steps apply to the single-user application (Compiled Database) and to the server (Client Server executable). During the build, the scheduled task that keeps the snapshot up to date is paused.

    The component in the delivered version

    • If your project declares the component as a GitHub dependency (see Installing BWEB), nothing to do: 4D downloads it when the delivered version first starts.
    • Otherwise, the build prepares a composant/ folder and an environment4d.json file pointing to it: put the component there by hand, under the name given in the LISEZMOI file. Without it, the application does not start.

    Git

    • The pending changes in your repository are all added (git add .) and committed with the message "version <v>" on the current branch.
    • A <v> branch is created and pushed, then the repository goes back to the starting branch.
    • The compiled application is pushed to a <v>C branch of the same remote. A remote is therefore required; if the output folder is itself inside a git repository, nothing is pushed.
    • On failure, the Retry Git and Open a terminal buttons appear. A synced folder (Dropbox, OneDrive) can lock .git: the log says so.

    On macOS

    The build also produces a disk image and, if the box is checked, signs it and has it notarized by Apple. Requirements: the Xcode command-line tools, a signing certificate declared in the build settings, and a keychain profile named notary_cred holding your Apple credentials. Notarization can take several minutes.

    The macOS chain has not yet been validated for a host application: test it before using it for a delivery.

    Good to know

    • The delivered version has no parameter file and no certificate: at a new server's first start, 4D asks for APP_PARAMETERS, and certificates are placed by hand.
    • Only the single-user and the server applications are prepared; 4D's client application and "final application" are not.

    See also