[build2] How to detect and configure #define macros?

[Joshua Olson]

I'll let you know when/if I finish the package. :)

libodb's cppget src-url property still looks the same to me from here.

I imagine it's easier for now not to make separate stub bpkgs for native
dependencies (I have no intention yet of maintaining them). On the topic of
maintenance burden - don't forget to give cppget package maintainers the
ability to transfer/share ownership.

Josh

On Tue, Nov 7, 2017 at 6:28 AM, Boris Kolpackov <boris at codesynthesis.com>
wrote:

> Joshua Olson <0joshua.olson1 at gmail.com> writes:
>
> > I'm gonna see if I can make a JUCE package...
>
> Sounds good. If you would like, I can publish it on cppget.org (in the
> future there will be an automated way to do it but for now I can do it
> manually if you give me a git repo).
>
>
> > Comment: the src-url of https://cppget.org/libodb is broken (
> > https://git.codesynthesis.com/cgit/?p=odb/libodb.git;a=tree says
> 'invalid
> > request')
>
> Fixed, thanks!
>
>
> > Question: if package A depends on a semi-popular package B being
> installed
> > (e.g. libcurl, webkit, gtk headers on Linux), is it ever preferable for
> > package B to be a bpkg too?
>
> Good question. In bpkg we have a notion of stub packages. Quoting from
> the bpkg manual[1]:
>
> "Version 0 (with a potential revision, for example, 0+1, 0+2) is used
> to signify a stub package. A stub is a package that does not contain
> source code and can only be "obtained" from other sources, for example,
> a system package manager. Note that at some point a stub may be converted
> into a full-fledged package at which point it will be assigned a "real"
> version."
>
> You can see an example of a stub here:
>
> https://git.build2.org/cgit/packaging/apr/libapr1/
>
> Currently, the only way to install a package via a stub is to tell bpkg
> that it is already system-installed, for example:
>
> $ bpkg build sys:libcurl libjuce
>
> In the future, however, we are thinking of having bpkg query the system
> package manager (e.g., apt, dnf, pkg, etc) and if the package is not
> installed, offering to install it.
>
> So, to put this all together, currently, if you do not want (yet) to
> package some dependencies but would like to list them as dependencies
> in the manifest, then the way to go is to create a stub.
>
> The reason you may at some point want to convert a stub to a full
> package is Windows: it doesn't have a system package manager (though
> I hear vcpkg may be becoming something like that) which makes
> installing dependencies painful. For example, we have started with
> libpq (PostgreSQL client library) as a stub but have now made it a
> real package which made life on Windows so much easier.
>
> [1] https://build2.org/bpkg/doc/build2-package-manager-manual.xhtml
>
> Boris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.build2.org/archives/users/attachments/20171107/81501ca7/attachment.html>