Prev: Conflict to solve between bazaar and gd
Next: stuff I'd like to have committed in time to make it into 8.1
From: Mario Sergio Fujikawa Ferreira on 15 Jun 2010 21:09
Hi,

Ever since the addition of graphics/libjpeg-turbo, I had
been wondering how one could possibly build the whole ports tree
with it instead of graphics/jpeg. I wanted the choice.

Therefore, I wrote the attached bsd.jpeg.mk as a suggestion.

With it, we just add

USE_JPEG= yes

to any port that requires a jpeg library (either a build or a link
dependency).

It will automagically detected the already installed jpeg
port variant (libjpeg-turbo or jpeg) and depend on it. If the user prefers to set the variant, he can do so using

WITH_JPEG= jpeg

or

WITH_JPEG= libjpeg-turbo

bsd.jpeg.mk will verify if the selected jpeg port WITH_JPEG
conflicts with an already installed version. If it doesn't, it will
be upheld. Otherwise, it will stop the build and tell the user that
his setting might be incorrect.

If a jpeg port has been neither installed nor selected
WITH_JPEG, bsd.jpeg.mk will default to the reliable graphics/jpeg
port.

Therefore, unless instructed otherwise everything will
depend upon graphics/jpeg. Only those systems that explicitly either
install graphics/libjpeg-turbo instead of jpeg OR select
WITH_JPEG=libjpeg-turbo will work differently.

Let me know what you think.

Regards,

ps: bsd.jpeg.mk structure is heavily based on bsd.database.mk so
thanks to everyone who contributed to it.

--
Mario S F Ferreira - DF - Brazil - "I guess this is a signature."
feature, n: a documented bug | bug, n: an undocumented feature
From: Peter Pentchev on 16 Jun 2010 04:56
On Tue, Jun 15, 2010 at 10:09:57PM -0300, Mario Sergio Fujikawa Ferreira wrote:
> Hi,
>
> Ever since the addition of graphics/libjpeg-turbo, I had
> been wondering how one could possibly build the whole ports tree
> with it instead of graphics/jpeg. I wanted the choice.
>
> Therefore, I wrote the attached bsd.jpeg.mk as a suggestion.
>
> With it, we just add
>
> USE_JPEG= yes
>
> to any port that requires a jpeg library (either a build or a link
> dependency).

Sounds great! Thanks for your work! Just one small worry, see below...

> It will automagically detected the already installed jpeg
> port variant (libjpeg-turbo or jpeg) and depend on it. If the user prefers to set the variant, he can do so using
>
> WITH_JPEG= jpeg
>
> or
>
> WITH_JPEG= libjpeg-turbo

Is it possible that this will conflict with ports that have a JPEG item
in their OPTIONS list? There are at least the astro/xplanet, editors/emacs,
graphics/devil, graphics/gdal, graphics/gegl, graphics/grx, graphics/imlib2,
graphics/ocaml-images, graphics/opencv, graphics/podofo, graphics/tumbler,
mail/spamprobe, math/R, multimedia/gmerlin, multimedia/gpac-libgpac,
multimedia/libquicktime, multimedia/spook, multimedia/transcode, x11/aterm,
x11-fm/thunar, x11/mrxvt-devel, and x11-wm/jwm ports that do that, and
there might be more that a simple fgrep -le WITH_JPEG -e WITHOUT_JPEG did
not catch.

G'luck,
Peter

--
Peter Pentchev roam(a)space.bg roam(a)ringlet.net roam(a)FreeBSD.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
From: Ade Lovett on 16 Jun 2010 05:38

On Jun 15, 2010, at 18:09 , Mario Sergio Fujikawa Ferreira wrote:

> Hi,
>
> Ever since the addition of graphics/libjpeg-turbo, I had
> been wondering how one could possibly build the whole ports tree
> with it instead of graphics/jpeg. I wanted the choice.
>
> Therefore, I wrote the attached bsd.jpeg.mk as a suggestion.

I have other concerns, but the fundamental one is bsd.jpeg.mk is way too specific, and could easily lead to bsd.tiff.mk, bsd.gd.mk, etc.. etc..

You might want to consider abstracting it out a little further (compare with bsd.database.mk) to, say, bsd.graphics.mk

It might then be possible to do weird and wonderful things like:

USE_GRAPHICS= jpeg-turbo openexr gd tiff

in ports Makefiles, and have them do the right thing, or at least offer up include and library paths, along with relevant *_DEPENDS additions.

It's a little more work in the short term, but there's plenty of existing Mk/* files to use as reference for parsing a possible USE_GRAPHICS stanza, and it is much more extensible.

-aDe

_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Scot Hetzel on 16 Jun 2010 11:29
On Wed, Jun 16, 2010 at 3:56 AM, Peter Pentchev <roam(a)ringlet.net> wrote:
> On Tue, Jun 15, 2010 at 10:09:57PM -0300, Mario Sergio Fujikawa Ferreira wrote:
>>       It will automagically detected the already installed jpeg
>> port variant (libjpeg-turbo or jpeg) and depend on it. If the user prefers to set the variant, he can do so using
>>
>> WITH_JPEG=    jpeg
>>
>> or
>>
>> WITH_JPEG=    libjpeg-turbo
>
> Is it possible that this will conflict with ports that have a JPEG item
> in their OPTIONS list?  There are at least the astro/xplanet, editors/emacs,
> graphics/devil, graphics/gdal, graphics/gegl, graphics/grx, graphics/imlib2,
> graphics/ocaml-images, graphics/opencv, graphics/podofo, graphics/tumbler,
> mail/spamprobe, math/R, multimedia/gmerlin, multimedia/gpac-libgpac,
> multimedia/libquicktime, multimedia/spook, multimedia/transcode, x11/aterm,
> x11-fm/thunar, x11/mrxvt-devel, and x11-wm/jwm ports that do that, and
> there might be more that a simple fgrep -le WITH_JPEG -e WITHOUT_JPEG did
> not catch.
>
Since many ports use JPEG as an item in their OPTIONS list to enable
jpeg support in the port, why not use WITH_JPEG_PORT to allow the
administrator to choose which jpeg port to depend on.

Scot
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Ion-Mihai Tetcu on 16 Jun 2010 18:11
On Wed, 16 Jun 2010 02:38:29 -0700
Ade Lovett <ade(a)FreeBSD.org> wrote:

>
> On Jun 15, 2010, at 18:09 , Mario Sergio Fujikawa Ferreira wrote:
>
> > Hi,
> >
> > Ever since the addition of graphics/libjpeg-turbo, I had
> > been wondering how one could possibly build the whole ports tree
> > with it instead of graphics/jpeg. I wanted the choice.
> >
> > Therefore, I wrote the attached bsd.jpeg.mk as a suggestion.
>
> I have other concerns, but the fundamental one is bsd.jpeg.mk is way
> too specific, and could easily lead to bsd.tiff.mk, bsd.gd.mk, etc..
> etc..
>
> You might want to consider abstracting it out a little further
> (compare with bsd.database.mk) to, say, bsd.graphics.mk
>
> It might then be possible to do weird and wonderful things like:
>
> USE_GRAPHICS= jpeg-turbo openexr gd tiff
>
> in ports Makefiles, and have them do the right thing, or at least
> offer up include and library paths, along with relevant *_DEPENDS
> additions.

Also, implementing at least min. versions for each depend is needed.

> It's a little more work in the short term, but there's plenty of
> existing Mk/* files to use as reference for parsing a possible
> USE_GRAPHICS stanza, and it is much more extensible.

My question is: do we really need this? We're at the point where in
order to make use of all macros, vars, etc. we have, one needs to work
daily on ports.


--
IOnut - Un^d^dregistered ;) FreeBSD "user"
"Intellectual Property" is nowhere near as valuable as "Intellect"
FreeBSD committer -> itetcu(a)FreeBSD.org, PGP Key ID 057E9F8B493A297B
 |  Next  |  Last
Pages: 1 2
Prev: Conflict to solve between bazaar and gd
Next: stuff I'd like to have committed in time to make it into 8.1