Re: automating menu options in ports (and other ports build questions)
On Thu, 24 May 2012 23:56:02 -0600, Gary Aitken wrote: > Is there a way to find out what options a package is built with? I don't think so. A package is just an archive containing "truncated subtrees" such as bin/, lib/ or man/ of the compiled programs, ready for install into the /usr/local directory. It also contains data files such as +COMMENT, +CONTENTS, +DESC and +MTREE_DIRS. However, if you have installed from a port, the options you have set will be stored in /var/db/ports//options. I haven't tested yet if a package that _has_ adjustable options (which obviously have already been adjusted) would create such a directory and file, but I assume it does not, as it seems obvious that those are handled by the port building mechanisms (which aren't in use when you pkg_add something). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: automating menu options in ports (and other ports build questions)
On Thu, 24 May 2012 23:55:17 -0600, Gary Aitken wrote: > >> 5. It looks like the options which show up using sysinstall are from the > >> OPTIONS variable in the Makefile. > > > > Excuse me, where exactly do you see compile-time options in the > > sysinstall program? I know it can select and install packages, > > but PORTS? > > What I mean is the OPTIONS variable is what shows up when >make config > is done (now that I understand it a little better) The menu functionality is provided by the ncurses-based "dialog" program and defined in /usr/ports/Mk/bsd.port.mk line 5953 +/- (version 1.692 here). > Unfortunately, lots-o-computers but only one screen :-( I know this situation very well. One just _cannot_ be familiar with all the many option names (that sometimes just sound like logorrhea) and that make _no_ sense unless you know what they mean. There are names where the meaning can be concluded, and so the question "Do I need it?" can be answered; sadly that's not always the case, especially when dealing with "modern" software and their partially ridiculous naming habits. > >> Or is this a documentation project in the offing? > > > > I would welcome a kind of text file that lists all the strange > > names with a short description of what they are and what you > > need them for, being more informative than the short "one liners" > > in the options dialog. > > Can someone point me at the code that puts up the menu? See /usr/ports/Mk/bsd.port.mk as mentioned above. The "dialog" program also offers some examples which belong to the base system, see /usr/share/examples/dialog, and of course see "man dialog". -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: automating menu options in ports (and other ports build questions)
On 05/24/12 23:34, Adam Vande More wrote: On Thu, May 24, 2012 at 8:51 PM, Polytropon wrote: On Thu, 24 May 2012 19:28:58 -0600, Gary Aitken wrote: 3. Do the package builds use the defaults set in the ports tree? If not, how are the options for packages chosen, and how does one determine what the package options are? They use the default options. This is true for most ports at least, but perhaps not true for all of them. For example the QT4_OPTIONS controls some rather critical functionality which is compiled into the packages however doesn't end up in a default port install without other modification in make.conf. It wouldn't surprise me at all if there were a few port config screens that didn't match a package's selected options. Is there a way to find out what options a package is built with? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: automating menu options in ports (and other ports build questions)
> I didn't see anything in the ports documentation, but maybe I'm blind. Check "man 7 ports". Doh. I'm blind. I've read that at least three times looking at other stuff. Makes sense now. Thanks especially because it's illegal to listen to MP3 in the U. S. :-) g... 5. It looks like the options which show up using sysinstall are from the OPTIONS variable in the Makefile. Excuse me, where exactly do you see compile-time options in the sysinstall program? I know it can select and install packages, but PORTS? What I mean is the OPTIONS variable is what shows up when make config is done (now that I understand it a little better) If you deal with ports, it's often useful to have a second system / terminal / computer / ... with a web browser so you can try to look up the meaning of options. If you don't have that, making a selection can be hard: ++ | Options for stupido 19.84 | | ++ | | | [ ] CUPS Enable support for printing (requires CUPS) | | | | [ ] GTK Use GTK backend | | | | [ ] KDE4 Use KDE4 backend in room 101 | | | | [ ] FUSE Enable FUSE | | | | [ ] OPENGL Use OpenGL graphics | | | | [ ] KLOMPATSHUse Klompatsh | | | | [ ] RHUMBOIREUse RHUMBOIRE backend | | | | [ ] QUEEKNARGEnable QUEEKNARG support | | | | [ ] ECK'N'POOT Build with COM-POO-TAIR module| | | | [ ] SHMEER Build bindings for Shmeer and Shmeerlappen| | | | [ ] SHLORTS Enable support for SHLORTS (requires GNOOLFS) | | | | [x] Use nothing, go away. | | +-++-+ | [ OK ] Cancel| ++ Unfortunately, lots-o-computers but only one screen :-( Super. I've been looking for bindings to Shmeerlappen for years. And my shlorts have needed support for a long time too. Or is this a documentation project in the offing? I would welcome a kind of text file that lists all the strange names with a short description of what they are and what you need them for, being more informative than the short "one liners" in the options dialog. Can someone point me at the code that puts up the menu? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: automating menu options in ports (and other ports build questions)
On Thu, May 24, 2012 at 8:51 PM, Polytropon wrote: > On Thu, 24 May 2012 19:28:58 -0600, Gary Aitken wrote: > > 3. Do the package builds use the defaults set in the ports tree? If > > not, how are the options for packages chosen, and how does one determine > > what the package options are? > > They use the default options. This is true for most ports at least, but perhaps not true for all of them. For example the QT4_OPTIONS controls some rather critical functionality which is compiled into the packages however doesn't end up in a default port install without other modification in make.conf. It wouldn't surprise me at all if there were a few port config screens that didn't match a package's selected options. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: automating menu options in ports (and other ports build questions)
On Thu, 24 May 2012, Gary Aitken wrote: 1. When building a port, the system uses sysinstall to set options for the build. ncurses, not systinstall, but yes. How does one configure those options so make can be run unattended? I didn't see anything in the ports documentation, but maybe I'm blind. In particular, how does one configure a dependent port for the options you want whenever it is built as part of a higher-level build? make config-recursive 4. Is there a discussion anywhere of whether or not one should turn on various optimizations? If these aren't turned on by default, but are safe, why aren't they the default? Is this a cross-platform build issue, and the default is to build for cross-platform? In general, if a port can benefit from certain optimizations, it will have an option for that. Setting optimizations system-wide breaks that. And the optimizations that many people try turn out to be detrimental. 5. It looks like the options which show up using sysinstall are from the OPTIONS variable in the Makefile. Is there any convention for where to find out more about the option other than the often useless text hint provided in the menu? e.g. gvfs has an option called FUSE Enable fuse which doesn't say which of the several software systems called FUSE this refers to e.g. OPENGL Use OpenGL graphics doesn't say much about why you would want to do that, what the opengl option actually does, ramifications, whether it will help only if your graphics card / driver supports it, etc. Mostly you would have to look in the Makefile and possibly in the application source for these. Or is this a documentation project in the offing? Well, there's ports(7), and some related chapters in the Handbook. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: automating menu options in ports (and other ports build questions)
On Thu, 24 May 2012 19:28:58 -0600, Gary Aitken wrote: > 1. When building a port, the system uses sysinstall to set options for > the build. No. The default options are set by the port maintainer, usually in the port's Makefile. > How does one configure those options so make can be run > unattended? You can use two approaches: a) Use "make config" or "make config-recursive" to to select all choices "in one rush", then start building. b) Use a port management tool to do what the commands under a) would do. For example, "portmaster --force-config" would do so. You can also use the port mangement tool's configuration file to store port-specific selections in a file. There's support for this "batch operation" style of working to avoid interaction. > I didn't see anything in the ports documentation, but maybe > I'm blind. Check "man 7 ports". > In particular, how does one configure a dependent port for > the options you want whenever it is built as part of a higher-level build? The "-recursive" targets ("make config-recursive et al.) do this. > 2. Do port builds deal with concurrency? > i.e. can I safely do a make install in two different ports subtrees > simultaneously? I think this highly depends. As soon as you _know_ there will be no "same dependency" occuring, it should be no problem. To avoid this, each port (and the dependencies it needs) could be build in a separate tree, but that could also mean doubled builds; it would also not fully solve the problem of concurrent installations. See the meaning of "building dependencies" and "run dependencies" which both tend to be installed to the (same!) system in order to be usable by the successive port building. > 3. Do the package builds use the defaults set in the ports tree? If > not, how are the options for packages chosen, and how does one determine > what the package options are? They use the default options. > 4. Is there a discussion anywhere of whether or not one should turn on > various optimizations? Depends. For example, if you want to make mplayer run on older systems, you will surely use some optimization and customization. You will also do so if you want all the codecs. Maybe some of the reasons why some options aren't set by default (and therefore not present in the automatically built packages) is patent-lawyer-intellectual-property-blah-pirate-blah stuff, especially because it's illegal to listen to MP3 in the U. S. :-) > If these aren't turned on by default, but are > safe, why aren't they the default? Maybe because there is no "general use benefit" in them? Not sure. See also explaination above. > Is this a cross-platform build > issue, and the default is to build for cross-platform? The ports tree is, if I interpret that correctly, platform-independent. So the selected options should be "best choice" for all supported platforms (and there's some selective logic in the port building infrastructure itself as well as in some of the Makefiles). > 5. It looks like the options which show up using sysinstall are from the > OPTIONS variable in the Makefile. Excuse me, where exactly do you see compile-time options in the sysinstall program? I know it can select and install packages, but PORTS? > Is there any convention for where to > find out more about the option other than the often useless text hint > provided in the menu? >e.g. gvfs has an option called > FUSE Enable fuse > which doesn't say which of the several software systems called FUSE this > refers to >e.g. OPENGL Use OpenGL graphics > doesn't say much about why you would want to do that, > what the opengl option actually does, ramifications, > whether it will help only if your graphics card / driver supports it, > etc. Ha, good question! :-) If you deal with ports, it's often useful to have a second system / terminal / computer / ... with a web browser so you can try to look up the meaning of options. If you don't have that, making a selection can be hard: ++ | Options for stupido 19.84 | | ++ | | | [ ] CUPS Enable support for printing (requires CUPS) | | | | [ ] GTK Use GTK backend | | | | [ ] KDE4 Use KDE4 backend in room 101 | | | | [ ] FUSE Enable FUSE | | | | [ ] OPENGL Use OpenGL graphics | | | | [ ] KLOMPATSHUse Klompatsh | | | | [ ] RHUMBOIREUse RHUMBOIRE backend | | | | [ ] QUEEKNARGEnable QUEEKNARG support | | | | [ ] ECK'N'POOT Build with COM-POO-TAIR module| | | | [ ] SHMEER Build bindings for Shmeer and Shmeerlappen| | | | [ ] SHLORTS
automating menu options in ports (and other ports build questions)
1. When building a port, the system uses sysinstall to set options for the build. How does one configure those options so make can be run unattended? I didn't see anything in the ports documentation, but maybe I'm blind. In particular, how does one configure a dependent port for the options you want whenever it is built as part of a higher-level build? 2. Do port builds deal with concurrency? i.e. can I safely do a make install in two different ports subtrees simultaneously? I attempted this with gnome2-lite and firefox and ended up with the firefox build barfing on tests in shared-mime-info -- one of the tests failed because a directory already existed. I had to deinstall and reinstall shared-mime-info and then restart the firefox make. The two builds actually ended up in the less likely scenario of trying to build the same dependency at roughly the same time. 3. Do the package builds use the defaults set in the ports tree? If not, how are the options for packages chosen, and how does one determine what the package options are? 4. Is there a discussion anywhere of whether or not one should turn on various optimizations? If these aren't turned on by default, but are safe, why aren't they the default? Is this a cross-platform build issue, and the default is to build for cross-platform? 5. It looks like the options which show up using sysinstall are from the OPTIONS variable in the Makefile. Is there any convention for where to find out more about the option other than the often useless text hint provided in the menu? e.g. gvfs has an option called FUSE Enable fuse which doesn't say which of the several software systems called FUSE this refers to e.g. OPENGL Use OpenGL graphics doesn't say much about why you would want to do that, what the opengl option actually does, ramifications, whether it will help only if your graphics card / driver supports it, etc. Or is this a documentation project in the offing? Thanks, Gary ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"