puredarwin default variant

[yves@…]

Hi

it would be neat to have puredarwin detected by darwinports. this works for me :

if {[info exists os.platform] && ${os.platform} == "darwin" && ![file exists /usr/bin/sw_vers] && ![info exists variations(puredarwin)]} { variant_set puredarwin }

I put it in the implicit variants section at the bottom of portmain.tcl

[danchr@…]

(In reply to comment #0)

if {[info exists os.platform] && ${os.platform} == "darwin" && ![file exists

/usr/bin/sw_vers] && ![info

exists variations(puredarwin)]} { variant_set puredarwin }

It would probably be better to check for "/System/Library/Frameworks/Carbon.framework/Carbon". Most software which relies on Mac OS X relies on one of the Apple-proprietary frameworks, and Carbon is probably the most ignificant one of them. AFAICT an open source version of Carbon is a bit less likely than an open source version of sw_vers ;)

[rshaw@…]

Does pure Darwin even have any frameworks? If so, which ones does it have? I've never actually seen a pure Darwin installation to be able to poke around in. I agree with Dan's idea that it should check for specific frameworks and not binaries (since the binaries could exist at some point, and framworks are less likely).

I'd be willing to commit these changes if I can get some more information on a pure Darwin system to properly implement this. I'd also like to add a "macosx" variant auto-set as well for the same purpose.

-rshaw

[danchr@…]

(In reply to comment #2)

Does pure Darwin even have any frameworks? If so, which ones does it have?

My OD partition contains the following:

/Volumes/OpenDarwin/Library/Frameworks: NCUtilFoundation.framework OpenAudio.framework

/Volumes/OpenDarwin/System/Library/Frameworks: AppleTalk.framework Kernel.framework CarbonCore.framework LDAP.framework CoreFoundation.framework Security.framework CoreServices.framework System.framework DirectoryService.framework SystemConfiguration.framework FWAUserLib.framework Tcl.framework IOKit.framework

/Volumes/OpenDarwin/System/Library/PrivateFrameworks: DirectoryServiceCore.framework gdb.framework DiskArbitration.framework liberty.framework NetInfo.framework mLAN.framework SecurityNssAsn1.framework mmalloc.framework SecurityNssPkcs12.framework opcodes.framework bfd.framework readline.framework binutils.framework

I'd be willing to commit these changes if I can get some more information on a

pure Darwin system to

properly implement this. I'd also like to add a "macosx" variant auto-set as

well for the same purpose.

Wouldn't that be redundant considering there is no other "unpure" Darwin than Mac OS X?

While on this topic, I'd suggest another approach (if it isn't too difficult): Allow e.g. /etc/ports/variants.conf to somehow define default variants. If none exists, the build system could install with some good defaults, e.g. +puredarwin on pure darwin systems.

[rshaw@…]

Thanks for the directory trees. This will help. I'll stare at this a little bit and determine the best framework (or frameworks) to test for.

The only reason I brought up the "+macosx" variant is because some ports have this defined. It might make more sense (as hinted by your statements) that these ports be changed to have a +puredarwin variant that does the opposite of that the current +macosx variant does.

I need to poke through the ports and see where puredarwin/macosx variants are defined and how they are used.

As to your variants.conf file suggestion, that might be another possible option to add. It could help with things like +ssl or +no_x11 etc.

-rshaw

[danchr@…]

(In reply to comment #4)

As to your variants.conf file suggestion, that might be another possible

option to add. It could help with

things like +ssl or +no_x11 etc.

I was thinking of that too :) One problem is that DP is terribly inconsistent when it comes to variants. Some examples I've encountered are: +gtk, +gtk1, +gtk2 +x11, +no_x11 +ssl, +nocrypto

With a variants.conf, you could even document some variants and +macosx could be reserved for things that integrate even further into the mac UI, e.g. Carbon Emacs.

[yves@…]

just my 2 cents

the first time I made a similar proposition , I proposed using a Framework test, but I was told that we never knows when someone will make a fake framework or something. sw_vers was proposed because, if it should ever become available on darwin, it would then return "Darwin" while macosx will still return "Mac OS X".

that's it

[jmpp@…]

(In reply to comment #5)

(In reply to comment #4)

As to your variants.conf file suggestion, that might be another possible

option to add. It could help with

things like +ssl or +no_x11 etc.

I was thinking of that too :) One problem is that DP is terribly inconsistent when it comes to variants. Some examples I've encountered are: +gtk, +gtk1, +gtk2 +x11, +no_x11 +ssl, +nocrypto

With a variants.conf, you could even document some variants and +macosx could be reserved for things that integrate even further into the mac UI, e.g. Carbon Emacs.

I've had the discussion about consistency in variant naming before, both on the dp list and on IRC, with people like Will and Eirc Hall (gh1). Consistency across all of dports/ in variant naming, regardless of category, is crucial for various reasons: you guys are listing some here, Will's Images constitutes another. Under the Images framework variants are cascaded down onto dependencies when building a port, so as to (at least try to) ensure that the whole of what's installed supports the functionality provided by the requested variant. As an example, if I try to build ethereal with ipv6 support, the Images framework will query libpcap for an ipv6 variant in order to fully provide the functionality; if for any reason libpcap were to provide said functionality under a different variant name, the cascading effect would be completely lost (ok, maybe ipv6 is not such a good example to illustrate this point, but a superficial scan over dports/ will surely bring much better ones). I believe this calls for a discussion regarding some guidelines with respect to variant convensions (not to say "policices"), both on their naming and on their very concept, because it's not the same to provide, say, ssl in the main body of the port and then take it away with a 'no_ssl' [1] variant, than writing a minimalistic port and providing added fuinctionality with different variants.The mixture of these two approaches can also break the cascading effect, among other things.

All these issues have to be carefully thought under the scope of Port Images, which for a long while already has been dictating the life of DarwinPorts.

-jmpp

[1] The inconsistency in variant naming used to exhibit examples as ridiculous as "no-x11" and "no_x11" variants (which were thankfully taken care of by gh1). The quoted gtk examples are also pretty ridiculous.

[danchr@…]

Perhaps another bug should be opened for this formulating a variant policy? It's something that's annoyed me for quite some time, so I might be able to offer some input, or possibly formulate a draft.

BTW, the most silly example I've met is xchat1, xchat2 and xchat-gnome: Three ports which all install a binary called 'xchat', and thus conflict.

[rshaw@…]

I'll work on the puredarwin variant setting and the possibility of variants.conf file.

I recommend opening another bug to address standarizing/creating policy on variant names

-rshaw

[rshaw@…]

Ok, I've implemented all three capabilities:

1. Sets +puredarwin on pure Darwin systems.
2. Sets +macosx on Mac OS X systems.
3. Adds optional variants.conf file capability.

Make sure you re-configure and re-install the base/ code and check your ports.conf file to enable the variants_conf setting, and define your variants in your variants.conf file.

Enjoy! -rshaw

[waqar@…]

I think we should stick with two, darwin and macosx. darwin variant builds on both darwin and Mac OS X and macosx variant only builds on Mac OS X. If there are both then macosx takes precedence on Mac OS X.

$.02

[rshaw@…]

We can't just have two. There are cases where some ports build differently on pure Darwin vs. Mac OS X, so saying "darwin" builds on both, and "macosx" only on Mac OS X is leaving out the case of only building on pure Darwin. Hence "darwin" applies to both, "puredarwin" to pure Darwin only, and "macosx" to Mac OS X only.

Not to mention, most ports are already using the above convention, so this keeps in line with that without having to force changes to existing port files.

-rshaw