BinDeps.jl: Tool for Building Binary Dependencies For Julia Modules

BinDeps.jl  

Easily build binary dependencies for Julia packages

FAQ

Since there seems to be a lot of confusion surrounding the package systems and the role of this package, before we get started looking at the actual package, I want to answer a few common questions:

What is BinDeps?

BinDeps is a package that provides a collection of tools to build binary dependencies for Julia packages.

Do I need to use this package if I want to build binary dependencies for my Julia package?

Absolutely not! The system is designed to give the maximum amount of freedom to the package author in order to be able to address any situation that one may encounter in the real world. This is achieved by simply evaluating a file called deps/build.jl (if it exists) in a package whenever it is installed or updated. Thus the following might perhaps be the simplest possible useful build.jl script one can imagine:

run(`make`)

I want to use BinDeps, but it is missing some functionality I need (e.g. a package manager)

Since BinDeps is written in Julia it is extensible with the same ease as the rest of Julia. In particular, defining new behavior, e.g. for adding a new package manager, consists of little more than adding a type and implementing a couple of methods (see the section on Interfaces) or the WinRPM package for an example implementation.

I like the runtime features that BinDeps provides, but I don't really want to use its build time capabilities. What do you recommend?

The easiest way to do this is probably just to declare a BuildProcess for all your declared dependencies. This way, your custom build process will be called whenever there is an unsatisfied library dependency and you may still use the BinDeps runtime features.

Is there anything I should keep in mind when extending BinDeps or writing my own build process?

BinDeps uses a fairly standard set of directories by default and if possible, using the same directory structure is advised. Currently the specified directory structure is:

deps/
    build.jl        # This is your build file
    downloads/      # Store any binary/source downloads here
    builds/
        dep1/       # out-of-tree build for dep1, is possible
        dep2/       # out-of-tree build for dep2, is possible
        ...
    src/
        dep1/       # Source code for dep1
        dep2/       # Source code for dep2
        ...
    usr/            # "prefix", install your binaries here
        lib/        # Dynamic libraries (yes even on Windows)
        bin/        # Excecutables
        include/    # Headers
        ...

The high level interface - Declaring dependencies

To get a feel for the high level interface provided by BinDeps, have a look at real-world examples. The build script from the GSL pakage illustrates the simple case where only one library is needed. On the other hand, the build script from the Cairo package uses almost all the features that BinDeps currently provides and offers a complete overview. Let's take it apart, to see exactly what's going on.

As you can see Cairo depends on a lot of libraries that all need to be managed by this build script. Every one of these library dependencies is introduced by the library_dependency function. The only required argument is the name of the library, so the following would be an entirely valid call:

foo = library_dependency("libfoo")

However, you'll most likely quickly run into the issue that this library is named differently on different systems. (If this happens, you will receive an error such as Provider Binaries failed to satisfy dependency libfoo.) This is why BinDeps provides the handy aliases keyword argument. So suppose our library is sometimes known as libfoo.so, but other times as libfoo-1.so or libfoo-1.0.0.dylib or even libbar.dll on windows, because the authors of the library decided to punish windows users. In either case, we can easily declare all these in our library dependency:

foo = library_dependency("libfoo", aliases = ["libfoo", "libfoo-1", "libfoo-1.0.0", "libbar"])

So far so good! There are a couple of other keyword arguments that are currently implemented:

• os = OS_NAME Limits this dependency to certain operating systems. The same could be achieved by using the OS-specific macro, but this setting applies to all uses of this dependency and avoids having to wrap all uses of this dependency in macros. Note that the os parameter must match the value of Base.OS_NAME on the target platform with the special exception that :Unix matches all Unix-like platforms (e.g. Linux, Mac OS X, FreeBSD) As an example, consider this line from the Cairo build script:

gettext = library_dependency("gettext", aliases = ["libgettext", "libgettextlib"], os = :Unix)

• depends = [dep1, dep2] Currently unused, but in the future will be used to keep track of the dependency graph between binary dependencies to allow parallel builds. E.g.:

cairo = library_dependency("cairo", aliases = ["libcairo-2", "libcairo"], depends = [gobject, fontconfig, libpng])

runtime::Bool Whether or not to consider this a runtime dependency. If false, its absence will not trigger an error at runtime (and it will not be loaded), but if it cannot be found at buildtime it will be installed. This is useful for build-time dependencies of other binary dependencies.

validate::Function You may pass a function to validate whether or not a certain library is usable, e.g. whether or not has the correct version. To do so, pass a function that takes (name,handle) as an argument and returns true if the library is usable and false it not. The name argument is either an absolute path or the library name if it is a global system library, while the handle is a handle that may be passed to dlsym to check library symbols or the return value of a function. Should the validation return false for a library that was installed by a provider, the provider will be instructed to force a rebuild.

function validate_cairo_version(name,handle)
    f = Libdl.dlsym_e(handle, "cairo_version")
    f == C_NULL && return false
    v = ccall(f, Int32,())
    return v > 10800
end
...
cairo = library_dependency("cairo", aliases = ["libcairo-2", "libcairo"], validate = validate_cairo_version)

Other keyword arguments will most likely be added as necessary.

The high level interface - Declaring build mechanisms

Alright, now that we have declared all the dependencies that we need let's tell BinDeps how to build them. One of the easiest ways to do so is to use the system package manager. So suppose we have defined the following dependencies:

foo = library_dependency("libfoo")
baz = library_dependency("libbaz")

Let's suppose that these libraries are available in the libfoo-dev and libbaz-dev in apt-get and that both libraries are installed by the baz or the baz1 yum package, and the baz pacman package. We may declare this as follows:

provides(AptGet, Dict("libfoo-dev" => foo, "libbaz-dev" => baz))
provides(Yum, ["baz", "baz1"], [foo, baz])
provides(Pacman, "baz", [foo, baz])

One may remember the provides function by thinking AptGet provides the dependencies foo and baz.

The basic signature of the provides function is

provides(Provider, data, dependency, options...)

where data is provider-specific (e.g. a string in all of the package manager cases) and dependency is the return value from library_dependency. As you saw above multiple definitions may be combined into one function call as such:

provides(Provider, Dict(data1=>dep1, data2=>dep2), options...)

which is equivalent to (and in fact will be internally dispatched) to:

provides(Provider, data1, dep1, options...)
provides(Provider, data2, dep2, options...)

If one provide satisfied multiple dependencies simultaneously, dependency may also be an array of dependencies (as in the Yum and Pacman cases above).

There are also several builtin options. Some of them are:

os = OS_NAME # e.g. :Linux, :Windows, :Darwin

This provider can only satisfy the library dependency on the specified os. This argument takes has the same syntax as the os keyword argument to library_dependency.

installed_libpath = "path"

If the provider installs a library dependency to someplace other than the standard search paths, that location can be specified here.

SHA = "sha"

Provides a SHA-256 checksum to validate a downloaded source or binary file against.

The high level interface - built in providers

We have already seen the AptGet and Yum providers, which all take a string naming the package as their data argument. The other build-in providers are:

Sources

Takes a URI object as its data argument and declared that the sources may be downloaded from the provided URI. This dependency is special, because it's success does not automatically mark the build as succeeded (in BinDeps terminology, it's a "helper"). By default this provider expects the unpacked directory name to be that of the archive downloaded. If that is not the case, you may use the :unpacked_dir option to specify the name of the unpacked directory, e.g.

provides(Sources,URI("http://libvirt.org/sources/libvirt-1.1.1-rc2.tar.gz"), libvirt,
    unpacked_dir = "libvirt-1.1.1")

Binaries

If given a URI object as its data argument, indicates that the binaries may be downloaded from the provided URI. It is assumed that the binaries unpack the libraries into usr/lib. If given a String as its data argument, provides a custom search path for the binaries. A typical use might be to allow the user to provide a custom path by using an environmental variable.

BuildProcess

Common super class of various kind of build processes. The exact behavior depends on the data argument. Some of the currently supported build processes are Autotools and SimpleBuild:

Autotools

A subclass of BuildProcess that that downloads the sources (as declared by the "Sources" provider) and attempts to install using Autotools. There is a plethora of options to change the behavior of this command. See the appropriate section of the manual (or even better, read the code) for more details on the available options.

Autotools(; options...)

SimpleBuild

A subclass of BuildProcess that takes any object that's part of the low-level interface and could be passed to run and simply executes that command.

The high level interface - Loading dependencies

To load dependencies without a runtime dependence on BinDeps, place code like the following near the start of the Package's primary file. Don't forget to change the error message to reflect the name of the package.

const depsfile = joinpath(dirname(@__FILE__), "..", "deps", "deps.jl")
if isfile(depsfile)
    include(depsfile)
else
    error("HDF5 not properly installed. Please run Pkg.build(\"HDF5\") then restart Julia.")
end

This will make all your libraries available as variables named by the names you gave the dependency. E.g. if you declared a dependency as

library_dependency("libfoo")

The libfoo variable will now contain a reference to that library that may be passed to ccall or similar functions.

The low level interface

The low level interface provides a number of utilities to write cross platform build scripts. It looks something like this (from the Cairo build script):

@build_steps begin
    GetSources(libpng)
    CreateDirectory(pngbuilddir)
    @build_steps begin
        ChangeDirectory(pngbuilddir)
        FileRule(joinpath(prefix,"lib","libpng15.dll"),@build_steps begin
            `cmake -DCMAKE_INSTALL_PREFIX="$prefix" -G"MSYS Makefiles" $pngsrcdir`
            `make`
            `cp libpng*.dll $prefix/lib`
            `cp libpng*.a $prefix/lib`
            `cp libpng*.pc $prefix/lib/pkgconfig`
            `cp pnglibconf.h $prefix/include`
            `cp $pngsrcdir/png.h $prefix/include`
            `cp $pngsrcdir/pngconf.h $prefix/include`
        end)
    end
end

All the steps are executed synchronously. The result of the @build_steps macro may be passed to run to execute it directly, thought this is not recommended other than for debugging purposes. Instead, please use the high level interface to tie the build process to dependencies.

Some of the builtin build steps are:

FileDownloader(remote_file,local_file)

Download a file from remote_file create it as local_file

FileUnpacker(local_file,folder)

Unpack the file `local_file` into the folder `folder`

AutotoolsDependency(opts...)

Invoke autotools. Use of this build step is not recommended. Use the high level interface instead

CreateDirectory(dir)

Create the directory dir

ChangeDirectory(dir)

cd into the directory dir and try to remain there for this build block. Must be the first command in a @build_steps block and will remain active for the entire block

MakeTargets([dir,],[args...],env)

Invoke make with the given arguments in the given directory with the given environment.

DirectoryRule(dir,step)

If dir does not exist invoke step and validate that the directory was created

FileRule([files...],step)

Like Directory rule, but validates the existence of any of the files in the files array`.

GetSources(dep)

Get the declared sources from the dependency dep and put them in the default download location

Diagnostics

A simple way to see what libraries are required by a package, and to detect missing dependencies, is to use BinDeps.debug("PackageName"):

julia> using BinDeps

julia> BinDeps.debug("Cairo")
INFO: Reading build script...
The package declares 1 dependencies.
 - Library Group "cairo" (satisfied by BinDeps.SystemPaths, BinDeps.SystemPaths)
     - Library "png" (not applicable to this system)
     - Library "pixman" (not applicable to this system)
     - Library "ffi" (not applicable to this system)
     - Library "gettext"
        - Satisfied by:
          - System Paths at /usr/lib64/preloadable_libintl.so
          - System Paths at /usr/lib64/libgettextpo.so
        - Providers:
          - BinDeps.AptGet package gettext (can't provide)
          - BinDeps.Yum package gettext-libs (can't provide)
          - Autotools Build

Download Details: 

Author: JuliaPackaging
Source Code: https://github.com/JuliaPackaging/BinDeps.jl 
License: View license

#julia #modules 

What is GEEK

Buddha Community

Binary MLM Software Demo | Binary Compensation Plan, MLM Woocommerce

Binary MLM Software Demo | Binary MLM Compensation Plan, MLM Woocommerce Price USA, Philippines : Binary MLM Woocommerce Software is a web application that integrate with the Woo-commerce plugin and helps to manage binary MLM networks. LETSCMS provide worldwide service, such as USA, Hong Kong, China, UK, UAE, Jordan, Saudi Arabia, Pakistan, Philippines, Japan, Singapore, Romania, Vietnam, Canada, Hong Kong, Russia, Hungary, Romania, Poland, Thailand, Laos and many others.

Binary MLM Woo-commerce includes a two legged structure where in a parent Node has two sub nodes where each new distributor or members is placed in either left or right sub-tree. One sub-tree is known as a Power Leg or Profit Leg while the second sub-tree is a Profit Leg or a weak leg.. It  is one of the basic Binary MLM plan which is required by all the MLM organizations be it small or large. The binary MLM plan helps admin managing users or sub nodes in a binary network to keep record of their income, expenses etc.

Admin Demo : https://wpbmw.mlmforest.com/wp-admin/admin.php?page=bmw-settings

Front Demo : https://wpbmw.mlmforest.com/?page_id=56

Features
Admin Features
Payout Reports.
Report to show complete details of an individual payouts.
Affiliate Commission.
Pair Commission .
Bonus Commission.
Specify eligibility criteria in the admin.
Configuration of commission and bonus details in the admin.
Service Charges for payout.
Run payouts manually.
Payout Detail based on user in admin .

Frontend Features
Register a Binary MLM User from provided registration page.
Register new Members using Genealogy.
New Join Network Page for non-Network Members .
MLM registration can happen by the Checkout page also.
Members can view full payout details in their account.

If you want to know more information and any queries regarding Binary MLM Woo-commerce, you can contact our experts through 
Skype: jks0586, 
Mail: letscmsdev@gmail.com, 
Website: www.letscms.com, www.mlmtrees.com,
Call/WhatsApp/WeChat: +91-9717478599.

more information : https://www.mlmtrees.com/product/binary-mlm-ecommerce

Vedio : https://www.youtube.com/watch?v=gji5XnnTJNc&list=PLn9cGkS1zw3QMCC-89p5zK39mPtfltkwq&index=5

 

#mlm_plan #Binary_mlm #binary_mlm_plan #Binary_mlm_wordpress_plugin #Binary_mlm_woo-commerce #binary_mlm_ecommerce #binary_mlm_software #binary_mlm_wp_plugin #biary_mlm_ecommerce #mlm_plan
 

BinDeps.jl: Tool for Building Binary Dependencies For Julia Modules

BinDeps.jl  

Easily build binary dependencies for Julia packages

FAQ

Since there seems to be a lot of confusion surrounding the package systems and the role of this package, before we get started looking at the actual package, I want to answer a few common questions:

What is BinDeps?

BinDeps is a package that provides a collection of tools to build binary dependencies for Julia packages.

Do I need to use this package if I want to build binary dependencies for my Julia package?

Absolutely not! The system is designed to give the maximum amount of freedom to the package author in order to be able to address any situation that one may encounter in the real world. This is achieved by simply evaluating a file called deps/build.jl (if it exists) in a package whenever it is installed or updated. Thus the following might perhaps be the simplest possible useful build.jl script one can imagine:

run(`make`)

I want to use BinDeps, but it is missing some functionality I need (e.g. a package manager)

Since BinDeps is written in Julia it is extensible with the same ease as the rest of Julia. In particular, defining new behavior, e.g. for adding a new package manager, consists of little more than adding a type and implementing a couple of methods (see the section on Interfaces) or the WinRPM package for an example implementation.

I like the runtime features that BinDeps provides, but I don't really want to use its build time capabilities. What do you recommend?

The easiest way to do this is probably just to declare a BuildProcess for all your declared dependencies. This way, your custom build process will be called whenever there is an unsatisfied library dependency and you may still use the BinDeps runtime features.

Is there anything I should keep in mind when extending BinDeps or writing my own build process?

BinDeps uses a fairly standard set of directories by default and if possible, using the same directory structure is advised. Currently the specified directory structure is:

deps/
    build.jl        # This is your build file
    downloads/      # Store any binary/source downloads here
    builds/
        dep1/       # out-of-tree build for dep1, is possible
        dep2/       # out-of-tree build for dep2, is possible
        ...
    src/
        dep1/       # Source code for dep1
        dep2/       # Source code for dep2
        ...
    usr/            # "prefix", install your binaries here
        lib/        # Dynamic libraries (yes even on Windows)
        bin/        # Excecutables
        include/    # Headers
        ...

The high level interface - Declaring dependencies

To get a feel for the high level interface provided by BinDeps, have a look at real-world examples. The build script from the GSL pakage illustrates the simple case where only one library is needed. On the other hand, the build script from the Cairo package uses almost all the features that BinDeps currently provides and offers a complete overview. Let's take it apart, to see exactly what's going on.

As you can see Cairo depends on a lot of libraries that all need to be managed by this build script. Every one of these library dependencies is introduced by the library_dependency function. The only required argument is the name of the library, so the following would be an entirely valid call:

foo = library_dependency("libfoo")

However, you'll most likely quickly run into the issue that this library is named differently on different systems. (If this happens, you will receive an error such as Provider Binaries failed to satisfy dependency libfoo.) This is why BinDeps provides the handy aliases keyword argument. So suppose our library is sometimes known as libfoo.so, but other times as libfoo-1.so or libfoo-1.0.0.dylib or even libbar.dll on windows, because the authors of the library decided to punish windows users. In either case, we can easily declare all these in our library dependency:

foo = library_dependency("libfoo", aliases = ["libfoo", "libfoo-1", "libfoo-1.0.0", "libbar"])

So far so good! There are a couple of other keyword arguments that are currently implemented:

• os = OS_NAME Limits this dependency to certain operating systems. The same could be achieved by using the OS-specific macro, but this setting applies to all uses of this dependency and avoids having to wrap all uses of this dependency in macros. Note that the os parameter must match the value of Base.OS_NAME on the target platform with the special exception that :Unix matches all Unix-like platforms (e.g. Linux, Mac OS X, FreeBSD) As an example, consider this line from the Cairo build script:

gettext = library_dependency("gettext", aliases = ["libgettext", "libgettextlib"], os = :Unix)

• depends = [dep1, dep2] Currently unused, but in the future will be used to keep track of the dependency graph between binary dependencies to allow parallel builds. E.g.:

cairo = library_dependency("cairo", aliases = ["libcairo-2", "libcairo"], depends = [gobject, fontconfig, libpng])

runtime::Bool Whether or not to consider this a runtime dependency. If false, its absence will not trigger an error at runtime (and it will not be loaded), but if it cannot be found at buildtime it will be installed. This is useful for build-time dependencies of other binary dependencies.

validate::Function You may pass a function to validate whether or not a certain library is usable, e.g. whether or not has the correct version. To do so, pass a function that takes (name,handle) as an argument and returns true if the library is usable and false it not. The name argument is either an absolute path or the library name if it is a global system library, while the handle is a handle that may be passed to dlsym to check library symbols or the return value of a function. Should the validation return false for a library that was installed by a provider, the provider will be instructed to force a rebuild.

function validate_cairo_version(name,handle)
    f = Libdl.dlsym_e(handle, "cairo_version")
    f == C_NULL && return false
    v = ccall(f, Int32,())
    return v > 10800
end
...
cairo = library_dependency("cairo", aliases = ["libcairo-2", "libcairo"], validate = validate_cairo_version)

Other keyword arguments will most likely be added as necessary.

The high level interface - Declaring build mechanisms

Alright, now that we have declared all the dependencies that we need let's tell BinDeps how to build them. One of the easiest ways to do so is to use the system package manager. So suppose we have defined the following dependencies:

foo = library_dependency("libfoo")
baz = library_dependency("libbaz")

Let's suppose that these libraries are available in the libfoo-dev and libbaz-dev in apt-get and that both libraries are installed by the baz or the baz1 yum package, and the baz pacman package. We may declare this as follows:

provides(AptGet, Dict("libfoo-dev" => foo, "libbaz-dev" => baz))
provides(Yum, ["baz", "baz1"], [foo, baz])
provides(Pacman, "baz", [foo, baz])

One may remember the provides function by thinking AptGet provides the dependencies foo and baz.

The basic signature of the provides function is

provides(Provider, data, dependency, options...)

where data is provider-specific (e.g. a string in all of the package manager cases) and dependency is the return value from library_dependency. As you saw above multiple definitions may be combined into one function call as such:

provides(Provider, Dict(data1=>dep1, data2=>dep2), options...)

which is equivalent to (and in fact will be internally dispatched) to:

provides(Provider, data1, dep1, options...)
provides(Provider, data2, dep2, options...)

If one provide satisfied multiple dependencies simultaneously, dependency may also be an array of dependencies (as in the Yum and Pacman cases above).

There are also several builtin options. Some of them are:

os = OS_NAME # e.g. :Linux, :Windows, :Darwin

This provider can only satisfy the library dependency on the specified os. This argument takes has the same syntax as the os keyword argument to library_dependency.

installed_libpath = "path"

If the provider installs a library dependency to someplace other than the standard search paths, that location can be specified here.

SHA = "sha"

Provides a SHA-256 checksum to validate a downloaded source or binary file against.

The high level interface - built in providers

We have already seen the AptGet and Yum providers, which all take a string naming the package as their data argument. The other build-in providers are:

Sources

Takes a URI object as its data argument and declared that the sources may be downloaded from the provided URI. This dependency is special, because it's success does not automatically mark the build as succeeded (in BinDeps terminology, it's a "helper"). By default this provider expects the unpacked directory name to be that of the archive downloaded. If that is not the case, you may use the :unpacked_dir option to specify the name of the unpacked directory, e.g.

provides(Sources,URI("http://libvirt.org/sources/libvirt-1.1.1-rc2.tar.gz"), libvirt,
    unpacked_dir = "libvirt-1.1.1")

Binaries

If given a URI object as its data argument, indicates that the binaries may be downloaded from the provided URI. It is assumed that the binaries unpack the libraries into usr/lib. If given a String as its data argument, provides a custom search path for the binaries. A typical use might be to allow the user to provide a custom path by using an environmental variable.

BuildProcess

Common super class of various kind of build processes. The exact behavior depends on the data argument. Some of the currently supported build processes are Autotools and SimpleBuild:

Autotools

A subclass of BuildProcess that that downloads the sources (as declared by the "Sources" provider) and attempts to install using Autotools. There is a plethora of options to change the behavior of this command. See the appropriate section of the manual (or even better, read the code) for more details on the available options.

Autotools(; options...)

SimpleBuild

A subclass of BuildProcess that takes any object that's part of the low-level interface and could be passed to run and simply executes that command.

The high level interface - Loading dependencies

To load dependencies without a runtime dependence on BinDeps, place code like the following near the start of the Package's primary file. Don't forget to change the error message to reflect the name of the package.

const depsfile = joinpath(dirname(@__FILE__), "..", "deps", "deps.jl")
if isfile(depsfile)
    include(depsfile)
else
    error("HDF5 not properly installed. Please run Pkg.build(\"HDF5\") then restart Julia.")
end

This will make all your libraries available as variables named by the names you gave the dependency. E.g. if you declared a dependency as

library_dependency("libfoo")

The libfoo variable will now contain a reference to that library that may be passed to ccall or similar functions.

The low level interface

The low level interface provides a number of utilities to write cross platform build scripts. It looks something like this (from the Cairo build script):

@build_steps begin
    GetSources(libpng)
    CreateDirectory(pngbuilddir)
    @build_steps begin
        ChangeDirectory(pngbuilddir)
        FileRule(joinpath(prefix,"lib","libpng15.dll"),@build_steps begin
            `cmake -DCMAKE_INSTALL_PREFIX="$prefix" -G"MSYS Makefiles" $pngsrcdir`
            `make`
            `cp libpng*.dll $prefix/lib`
            `cp libpng*.a $prefix/lib`
            `cp libpng*.pc $prefix/lib/pkgconfig`
            `cp pnglibconf.h $prefix/include`
            `cp $pngsrcdir/png.h $prefix/include`
            `cp $pngsrcdir/pngconf.h $prefix/include`
        end)
    end
end

All the steps are executed synchronously. The result of the @build_steps macro may be passed to run to execute it directly, thought this is not recommended other than for debugging purposes. Instead, please use the high level interface to tie the build process to dependencies.

Some of the builtin build steps are:

FileDownloader(remote_file,local_file)

Download a file from remote_file create it as local_file

FileUnpacker(local_file,folder)

Unpack the file `local_file` into the folder `folder`

AutotoolsDependency(opts...)

Invoke autotools. Use of this build step is not recommended. Use the high level interface instead

CreateDirectory(dir)

Create the directory dir

ChangeDirectory(dir)

cd into the directory dir and try to remain there for this build block. Must be the first command in a @build_steps block and will remain active for the entire block

MakeTargets([dir,],[args...],env)

Invoke make with the given arguments in the given directory with the given environment.

DirectoryRule(dir,step)

If dir does not exist invoke step and validate that the directory was created

FileRule([files...],step)

Like Directory rule, but validates the existence of any of the files in the files array`.

GetSources(dep)

Get the declared sources from the dependency dep and put them in the default download location

Diagnostics

A simple way to see what libraries are required by a package, and to detect missing dependencies, is to use BinDeps.debug("PackageName"):

julia> using BinDeps

julia> BinDeps.debug("Cairo")
INFO: Reading build script...
The package declares 1 dependencies.
 - Library Group "cairo" (satisfied by BinDeps.SystemPaths, BinDeps.SystemPaths)
     - Library "png" (not applicable to this system)
     - Library "pixman" (not applicable to this system)
     - Library "ffi" (not applicable to this system)
     - Library "gettext"
        - Satisfied by:
          - System Paths at /usr/lib64/preloadable_libintl.so
          - System Paths at /usr/lib64/libgettextpo.so
        - Providers:
          - BinDeps.AptGet package gettext (can't provide)
          - BinDeps.Yum package gettext-libs (can't provide)
          - Autotools Build

Download Details: 

Author: JuliaPackaging
Source Code: https://github.com/JuliaPackaging/BinDeps.jl 
License: View license

#julia #modules 

Homebrew.jl: OSX Binary dependency provider for Julia

Unmaintained

Note: This package is unmaintained, all users are strongly encouraged to use JLL packages for their binary needs.

Homebrew.jl (OSX only)

Homebrew.jl sets up a homebrew installation inside your Julia package directory. It uses Homebrew to provide specialized binary packages to satisfy dependencies for other Julia packages, without the need for a compiler or other development tools; it is completely self-sufficient.

Package authors with dependencies that want binaries distributed in this manner should open an issue here for inclusion into the package database.

NOTE: If you have MacPorts installed, and are seeing issues with git or curl complaining about certificates, try to update the the curl and curl-ca-bundle packages before using Homebrew.jl. From the terminal, run:

port selfupdate
port upgrade curl curl-ca-bundle

Usage (Users)

As a user, you ideally shouldn't ever have to use Homebrew directly, short of installing it via Pkg.add("Homebrew"). However, there is a simple to use interface for interacting with the Homebrew package manager:

• Homebrew.add("pkg") will install pkg, note that if you want to install a package from a non-default tap, you can do so via Homebrew.add("user/tap/formula"). An example of this is installing the metis4 formula from the Homebrew/science tap via Homebrew.add("homebrew/science/metis4").
• Homebrew.rm("pkg") will uninstall pkg
• Homebrew.update() will update the available formulae for installation and upgrade installed packages if a newer version is available
• Homebrew.list() will list all installed packages and versions
• Homebrew.installed("pkg") will return a Bool denoting whether or not pkg is installed
• Homebrew.prefix() will return the prefix that all packages are installed to

Usage (Package Authors)

As a package author, the first thing to do is to write/find a Homebrew formula for whatever package you wish to create. The easiest way to tell if the binary will work out-of-the-box is Homebrew.add() it. Formulae from the default homebrew/core tap need no prefix, but if you are installing something from another tap, you need to prefix it with the appropriate tap name. For example, to install metis4 from the homebrew/science tap, you would run Homebrew.add("homebrew/science/metis4"). Programs installed to <prefix>/bin and libraries installed to <prefix>/lib will automatically be availble for run()'ing and dlopen()'ing.

If that doesn't "just work", there may be some special considerations necessary for your piece of software. Open an issue here with a link to your formula and we will discuss what the best approach for your software is. To see examples of formulae we have already included for special usage, peruse the homebrew-juliadeps repository.

To have your Julia package automatically install these precompiled binaries, Homebrew.jl offers a BinDeps provider which can be accessed as Homebrew.HB. Simply declare your dependency on Homebrew.jl via a @osx Homebrew in your REQUIRE files, create a BinDeps library_dependency and state that Homebrew provides that dependency:

using BinDeps
@BinDeps.setup
nettle = library_dependency("nettle", aliases = ["libnettle","libnettle-4-6"])

...
# Wrap in @osx_only to avoid non-OSX users from erroring out
@osx_only begin
    using Homebrew
    provides( Homebrew.HB, "nettle", nettle, os = :Darwin )
end

@BinDeps.install Dict(:nettle => :nettle)

Then, the Homebrew package will automatically download the requisite bottles for any dependencies you state it can provide. This example garnered from the build.jl file from Nettle.jl package.

Why Package Authors should use Homebrew.jl

A common question is why bother with Homebrew formulae and such when a package author could simply compile the .dylib's needed by their package, upload them somewhere and download them to a user's installation somewhere. There are multiple reasons, and although they are individually surmountable Homebrew offers a simpler (and standardized) method of solving many of these problems automatically:

On OSX shared libraries link via full paths. This means that unless you manually alter the path inside of a .dylib or binary to have an @rpath or @executable_path in it, the path will be attempting to point to the exact location on your harddrive that the shared library was found at compile-time. This is not an issue if all libraries linked to are standard system libraries, however as soon as you wish to link to a library in a non-standard location you must alter the paths. Homebrew does this for you automatically, rewriting the paths during installation via install_name_tool. To see the paths embedded in your libraries and executable files, run otool -L <file>.

Dependencies on other libraries are handled gracefully by Homebrew. If your package requires some heavy-weight library such as cairo, glib, etc... Homebrew already has those libraries ready to be installed for you.

Releasing new versions of binaries can be difficult. Homebrew.jl has builtin mechanisms for upgrading all old packages, and even detecting when a binary of the same version number has a new revision (e.g. if an old binary had an error embedded inside it).

Why doesn't this package use my system-wide Homebrew installation?

Some of the formulae in the staticfloat/juliadeps tap are specifically patched to work with Julia. Some of these patches have not (or will not) be merged back into Homebrew mainline, so we don't want to conflict with any packages the user may or may not have installed.

Users can modify Homebrew's internal workings, so it's better to have a known good Homebrew installation than to risk bug reports from users that have unknowingly merged patches into Homebrew that break functionality we require.

If you already have something installed, and it is usable, (e.g. BinDeps can load it and it passes any quick internal tests the Package authors have defined) then Homebrew.jl won't try to install it. BinDeps always checks to see if there is a library in the current load path that satisfies the requirements setup by package authors, and if there is, it doesn't build anything.

Advanced usage

Homebrew.jl provides a convenient wrapper around most of the functionality of Homebrew, however there are rare cases where access to the full suite of brew commands is necessary. To facilitate this, users that are familiar with the brew command set can use Homebrew.brew() to directly feed commands to the brew binary within Homebrew.jl. Example usage:

julia> using Homebrew

julia> Homebrew.brew(`info staticfloat/juliadeps/libgfortran`)
staticfloat/juliadeps/libgfortran: stable 6.2 (bottled)
http://gcc.gnu.org/wiki/GFortran
/Users/sabae/.julia/v0.5/Homebrew/deps/usr/Cellar/libgfortran/6.2 (9 files, 2M) *
  Poured from bottle on 2016-11-21 at 13:14:33
From: https://github.com/staticfloat/homebrew-juliadeps/blob/master/libgfortran.rb
==> Dependencies
Build: gcc ✘

Download Details: 

Author: JuliaPackaging
Source Code: https://github.com/JuliaPackaging/Homebrew.jl 
License: View license

#julia #binary 

Qlab.jl: Generic Lab tools in Julia

Qlab.jl

Data manipulation and analysis tools tailored for quantum computing experiments in conjunction with Auspex. Currently working with Julia v1.0.

Installation

(v1.3) pkg> add https://github.com/BBN-Q/Qlab.jl

The code base also uses some system tools and python libraries for building libraries and plotting data with PyPlot.jl. You'll want to make sure your system has these.

In CentOS:

yum -y install epel-release
yum install gcc gcc-c++ make bzip2 hdf5 libaec libgfortran libquadmath

In Ubuntu/Debian:

apt-get install gcc g++ gcc-7-base make libaec0 libgfortran4 libhdf5-100 libquadmath0 libsz2

Python

You'll need a working version of PyPlot. In some cases the package manager has trouble getting this right on all systems/OSs. If you run into issues, we recommend using Conda.jl manually:

using Pkg
Pkg.add("PyCall")
Pkg.add("Conda")
ENV["PYTHON"] = ""
Pkg.build("PyCall")
using Conda
Conda.add("matplotlib")
Conda.add("seaborn")
Pkg.add("PyPlot")

In most cases, Julia should take care of this for you.

Other dependancies

Qlab.jl depends on several other Julia packages that have biniary dependencies. These should mostly be taken care of by the package manager. One important exception is HDF5 and its libhdf5 dependancy. This library manages the handling of HDF5 files and is currently maintained for backwards compatibility. The version of libhdf5 which produced any data files you want to analyze must match the library version used to create the files. You may need to add the path the the right version of libhdf5 to the Libdl path in Julia and rebuild HDF5:

push!(Libdl.DL_LOAD_PATH, "/opt/local/lib")
Pkg.build("HDF5")

where /opt/local/lib is the path to the correct version of libhdf5. See the documentation from HDF5.jl for more details. Currently only version of hdf5 1.8.2 - 1.8.17 are supported. If you're not planning to use HDF5 files, you shouldn't have to worry about the library versions matching.

Copyright

Raytheon BBN Technologies.

Download Details:

Author: BBN-Q
Source Code: https://github.com/BBN-Q/Qlab.jl 
License: View license

#julia #tool 

PkgUtils.jl: Tools for analyzing Julia Packages

PkgUtils.jl

This package contains tools for analyzing Julia packages.

For now, it provides tools to build a highly simplified package search engine that can be queried as a service:

Example

Build a simplified search engine service:

using PkgUtils
PkgUtils.runservice()

Run a search website:

cd .julia/PkgUtils
julia scripts/server.jl
open site/index.html

Download Details:

Author: johnmyleswhite
Source Code: https://github.com/johnmyleswhite/PkgUtils.jl 

#julia #utils #tool