gen is already installed, it will not be reinstalled with those
> variants.
The thing is that that's not what I'm seeing. Maybe depends_build is different
in that aspect than depends_lib?
> > I don't know if doxygen itself installs any libraries or headers; if not,
> &
ay, at least.
>
>> I'd like to use `depends_build-append port:doxygen` for +docs variants, but
>>
>> - calling the variant +docs causes port:doxygen to install (or reinstalll!)
>> with +docs, which adds lots of dependencies, and big ones at that (TeX)
If you &qu
> On Sep 22, 2016, at 9:07 AM, René J.V. Bertin wrote:
>
> Is there a way to stop certain variants from propagating to dependencies?
I'm pretty sure there is no way to do this. No clean way, at least.
> I'd like to use `depends_build-append port:doxygen` for +docs varian
Hi,
Is there a way to stop certain variants from propagating to dependencies?
I'd like to use `depends_build-append port:doxygen` for +docs variants, but
- calling the variant +docs causes port:doxygen to install (or reinstalll!)
with +docs, which adds lots of dependencies, and big on
On Aug 11, 2012, at 04:09, Joshua Root wrote:
> On 2012-8-11 18:54 , Clemens Lang wrote:
>> - TextMate 2 uses ninja as build system. Since we have the archcheck
>>for build dependencies, ninja will get installed +universal,
>>although the i386 code will never be executed at all, because
On 2012-8-11 19:33 , Clemens Lang wrote:
> This was a misunderstanding, because I didn't know
> how depends_skip_archcheck works (it's not documented!).
Doh. Guess someone should probably fix that...
- Josh
___
macports-dev mailing list
macports-dev@lis
On Sat, Aug 11, 2012 at 07:25:58PM +1000, Joshua Root wrote:
> I don't follow. If they need to be a particular arch, how can not
> doing the arch check be OK?
The library dependencies need to be a particular arch, the build
dependencies do not. This was a misunderstanding, because I didn't know
ho
xample where it would
> be needed?
A port that provides only a static lib goes in depends_build. A python
module with C extensions may only require another python module with C
extensions at runtime.
> I can not use depends_skip_archcheck, because the lib dependencies
> actually need to be
On Sat, Aug 11, 2012 at 07:02:21PM +1000, Joshua Root wrote:
> It is needed in the general case; when it's not and it makes a
> difference, use depends_skip_archcheck.
What general case requires it? Can you provide an example where it would
be needed?
I can not use depends_skip_archcheck, because
On 2012-8-11 18:54 , Clemens Lang wrote:
> - TextMate 2 uses ninja as build system. Since we have the archcheck
> for build dependencies, ninja will get installed +universal,
> although the i386 code will never be executed at all, because
> setting build.cmd to ninja will not magicall
On 2012-8-11 18:54 , Clemens Lang wrote:
> Any comments?
It is needed in the general case; when it's not and it makes a
difference, use depends_skip_archcheck.
- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforg
&& $active_archs != "" && $active_archs != "noarch" && $required_archs != "noarch"
-&& [lsearch -exact $depends_skip_archcheck $dep_portname] == -1} {
+if {$deptype != "depends_fetch" &
On Nov 19, 2011, at 12:50 PM, Joshua Root wrote:
> 'port deps' would answer this question. The dependency is needed, but
> setting fetch.type to git appends it automatically (actually to
> depends_fetch since that's the appropriate type).
Ah, ok, thanks for clarifying also this one. So I can safely
On 2011-11-19 22:41 , Marko Käning wrote:
> When I want to make sure that a port can be fetched via git is this port file
> addition:
> ---
> depends_build-append port:git-core
> ---
> actually needed or will it implicitly being handled by macports itself,
> becau
When I want to make sure that a port can be fetched via git is this port file
addition:
---
depends_build-append port:git-core
---
actually needed or will it implicitly being handled by macports itself, because
fetch.type already knows what's necessary.
(Now that I think about
On Aug 21, 2011, at 05:35, Anders F Björklund wrote:
> Anyway, build.cmd will have the path to the right make:
>
> build.type gnu
>
> build.env MAKE=${build.cmd}
>
> Both bsdmake and gnumake are provided by base, so there's
> no reason to use port dependencies unless *really* needed.
For examp
Mark Brethen wrote:
>> If it really makes a difference, you can set "build.type gnu".
>> That will make it use GNU make, even if it isn't the default...
>>
>> On Mac OS X, "make" is a symlink to gnumake so it's already
>> the default and it's mostly something like "platforms darwin"
>>
> After s
ell you can probably survive without having autoconf
>>>and automake, but if you have them you should use a reasonably up to
>>>date version.
>>> For CSL you need a C/C++ development context.
>>>
>>> These are common. Is it necessary to include them in a
On Aug 17, 2011, at 4:40 AM, M.E. O'Neill wrote:
>
> FWIW, as much as possible, I believe that if something uses traditional
> Unix/POSIX tools like awk, sed, or sh and requires GNU extensions, it's worth
> taking up with the upstream author, because their software won't build out of
> the box
Ryan Schmidt wrote:
> Sorry, you're right of course. I guess I was thinking of some other utilities
> on Mac OS X, like sed, which are BSD versions, whereas Linux typically has
> GNU versions, and this difference can sometimes affect ports.
FWIW, as much as possible, I believe that if something
On Aug 17, 2011, at 03:27, M.E. O'Neill wrote:
> Ryan Schmidt wrote:
>> Mac OS X (well, Xcode) has BSD make.
>
> Uh, no -- at least not the way you seem to be thinking.
>
> % /usr/bin/make --version
> GNU Make 3.81
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; s
ou have them you should use a reasonably up to
>> date version.
>> For CSL you need a C/C++ development context.
>>
>> These are common. Is it necessary to include them in a depends_build
>> statement?
>
> If reduce-algebra's build system calls auto
Ryan Schmidt wrote:
> Mac OS X (well, Xcode) has BSD make.
Uh, no -- at least not the way you seem to be thinking.
% /usr/bin/make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not ev
On Aug 16, 2011, at 23:17, Mark Brethen wrote:
> When is the depends_build keyword necessary?
Build dependencies are necessary when they're necessary, of course. :) Same as
library, runtime, fetch, and extract dependencies. The documentation of the
software you're creating a
When is the depends_build keyword necessary? For example, the reduce-algebra
build doc has this:
GNU make (other versions of "make" are not liable to work), autoconf
and automake. Well you can probably survive without having autoconf
and automake, but if you have them you
Was this ever addressed? If so, can someone point me to some info about it
because I missed it. I found another case where we might want to say "I don't
care". Totem (media player) pulls in a bunch of plugins. Some of these don't
build for certain archs, but we don't care because they're plu
On May 29, 2010, at 18:13, Joshua Root wrote:
> On 2010-5-30 09:05 , Ryan Schmidt wrote:
>> you've said there are no known regressions in 1.9.0-rc2, but this is one of
>> the three problems that I consider regressions.
>
> What are the other two, and why aren't there tickets for them?
Well, I al
On 2010-5-30 09:37 , Ryan Schmidt wrote:
>
> On May 29, 2010, at 18:25, Joshua Root wrote:
>
>> On 2010-5-30 09:18 , Joshua Root wrote:
>>> On 2010-5-30 09:15 , Ryan Schmidt wrote:
On May 29, 2010, at 18:10, Joshua Root wrote:
> and code generators, to name two.
Do you mean lik
On May 29, 2010, at 18:25, Joshua Root wrote:
> On 2010-5-30 09:18 , Joshua Root wrote:
>> On 2010-5-30 09:15 , Ryan Schmidt wrote:
>>> On May 29, 2010, at 18:10, Joshua Root wrote:
and code generators, to name two.
>>>
>>> Do you mean like swig, or what would be a code generator?
>>
>> GC
On 2010-5-30 09:18 , Joshua Root wrote:
> On 2010-5-30 09:15 , Ryan Schmidt wrote:
>> On May 29, 2010, at 18:10, Joshua Root wrote:
>>> On 2010-5-30 09:05 , Ryan Schmidt wrote:
Basically, is there any situation where checking the architecture of a
build dependency is known to be necessar
On 2010-5-30 09:15 , Ryan Schmidt wrote:
> On May 29, 2010, at 18:10, Joshua Root wrote:
>> On 2010-5-30 09:05 , Ryan Schmidt wrote:
>>> Basically, is there any situation where checking the architecture of a
>>> build dependency is known to be necessary?
>>
>> Static libs
>
> ...I had not tho
On May 29, 2010, at 18:10, Joshua Root wrote:
> On 2010-5-30 09:05 , Ryan Schmidt wrote:
>> Basically, is there any situation where checking the architecture of a build
>> dependency is known to be necessary?
>
> Static libs
...I had not thought of that. Damn. :) I retract my objection.
> a
On 2010-5-30 09:05 , Ryan Schmidt wrote:
> you've said there are no known regressions in 1.9.0-rc2, but this is one of
> the three problems that I consider regressions.
What are the other two, and why aren't there tickets for them?
- Josh
___
macports-
On 2010-5-30 09:05 , Ryan Schmidt wrote:
> On May 29, 2010, at 16:58, Joshua Root wrote:
>
>>> $ sudo port -v install xorg-server
>>> Error: Cannot install xorg-server for the arch(s) 'i386 x86_64' because
>>> Error: its dependency doxygen is only installed for the arch 'x86_64'
>>> Error: and doe
On May 29, 2010, at 16:58, Joshua Root wrote:
>> $ sudo port -v install xorg-server
>> Error: Cannot install xorg-server for the arch(s) 'i386 x86_64' because
>> Error: its dependency doxygen is only installed for the arch 'x86_64'
>> Error: and does not have a universal variant.
>> Error: Unable
On 2010-5-30 06:06 , Jeremy Huddleston wrote:
> We can handle packages that have not architecture (xorg protos and other
> "data" ports), but there doesn't seem to be a way to work around needing an
> executable (don't care about arch) as a build dependency... Eg:
>
> $ sudo port -v install xul
We can handle packages that have not architecture (xorg protos and other "data"
ports), but there doesn't seem to be a way to work around needing an executable
(don't care about arch) as a build dependency... Eg:
$ sudo port -v install xulrunner-devel +internal_dependencies
Error: Cannot instal
On Aug 6, 2007, at 17:37, Mark Duling wrote:
Kevin Van Vechten writes:
Why do we have depends_lib, depends_build and depends_run? Why not
just a single "depends"? Why does it matter which phase requires
the
other software? Isn't it enough to know that the other software is
r
Le 07-08-06 à 04:22, Randall Wood a écrit :
A dependency is considered satisfied if the dependency is
installed, not if it is activated. I think this should be
considered a bug.
It is
https://trac.macosforge.org/projects/macports/ticket/7361
yves
Kevin Van Vechten >> Why do we have depends_lib, depends_build and depends_run? Why not
>>> just a single "depends"? Why does it matter which phase requires the
>>> other software? Isn't it enough to know that the other software is
>>> required at
On Aug 6, 2007, at 10:07 AM, [EMAIL PROTECTED] wrote:
Why do we have depends_lib, depends_build and depends_run? Why not
just a single "depends"? Why does it matter which phase requires the
other software? Isn't it enough to know that the other software is
required at som
Oops. Resending to the list with the correct address minus the cc's.
>Have various dependency questions here. I couldn't find info on this
>in the new guide.
>
>Why do we have depends_lib, depends_build and depends_run? Why not
>just a single "depends&qu
5 Aug 2007, at 04:41, Ryan Schmidt wrote:
Have various dependency questions here. I couldn't find info on
this in the new guide.
Why do we have depends_lib, depends_build and depends_run? Why not
just a single "depends"? Why does it matter which phase requires
the other sof
Have various dependency questions here. I couldn't find info on this
in the new guide.
Why do we have depends_lib, depends_build and depends_run? Why not
just a single "depends"? Why does it matter which phase requires the
other software? Isn't it enough to know that t
44 matches
Mail list logo
