Dan Nicholson wrote these words on 12/20/05 16:42 CST: > On 12/20/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > >>7) Here are some thoughts about the options Dan had in his file, > >>ac_add_options --enable-system-cairo >> >>(I didn't use this option as enabling cairo is not a Firefox >> default. We can enable it, but we need to tell everyone why >> we are enabling it, and *exactly* what it provides, and how >> it make the build better.) > > If you --enable-svg, it will use the internal copy of cairo. This is > recent, so that's not the issue, but it's in the same boat as zlib, > jpeg, etc. Someone else can argue the benefits of reusing your system > libs, but that's the reason.
Actually, Dan, it is not a similar issue. Jpeg, libpng and zlib are all used regardless. Either the system copy or the copy in the source tree. It sounds to me, however, that cairo is only used if you pass a special parameter. Note, however, I am open to using it. But someone is going to have to provide a very good explanation of what --enable-svg does, why we need it, and what benefit it does for the user. >>ac_add_options --enable-svg # enable svg support >> >>(as best as I can tell this option is on by default. Including >>it is redundant) > > This is off by default. MOZ_SVG is not set unless you pass > --enable-svg. In turn it uses cairo to do the svg unless you > --enable-svg-renderer=something_else. You obviously have done more homework than me. I was going on the fact that not using --enable-svg and because about:config shows that the svg.enabled parameter is set to status:true. What exactly does that mean then? Furthermore, in order to use --enable-svg we'll need to come up with: 1. What it does. 2. Why we need it. 3. What added functionality does it give us. 4. What functionality is lost if you don't have it. >>ac_add_options --enable-canvas # enable html:canvas feature > > http://developer.mozilla.org/en/docs/Category:HTML:Canvas I now see what it does. Thanks for the link. Best I can tell there is no harm in using it, doesn't cause any overhead, and only can provide additional functionality (that nobody has implemented yet, probably) :-) >>mk_add_options BUILD_OFFICIAL=1 >>mk_add_options MOZILLA_OFFICIAL=1 >>export BUILD_OFFICIAL=1 >>export MOZILLA_OFFICIAL=1 >> >>(I'm not sure these are necessary any longer. I didn't use them >>and can't notice any difference in functionality with Firefox. > > I think these are historical and unnecessary. I couldn't find any way > they affected the build. I think so now as well. I thought it had to do with perhaps rendering/creating some "official" icons and such, but I discovered that with/without them, my builds are the same. The difference I was seeing was running it in the dist subdir of the object dir or in an installed dir (and you describe this below) > I wrote an email about this sometime back, but no one said anything, > so I kept quiet. The fix is trivial. You need an xpm in > /usr/lib/firefox-1.5/chrome/icons/default. One isn't installed in the > make install method. For the packaged method it is. I have a patch > for this to a Makefile.in, but it's probably simpler to just do it in > a command. > > Simple fix: > mkdir -pv /usr/lib/firefox-1.5/chrome/icons/default > cp -v /usr/lib/firefox-1.5/icons/default.xpm > /usr/lib/firefox-1.5/chrome/icons/default Again, thanks, dude. This one will have to go in for sure. :-) >>ac_add_options \ >> --with-default-mozilla-five-home=/usr/lib/firefox-1.5 # >> MOZILLA_FIVE_HOME >> >>(this one is included above in the file I used, but like Andy, I >>wonder about its usefulness. Though I argued for it, I did quite >>a bit of testing where I left it off (and also intentionally put >>in a different directory in the command than it should be, i.e., >>where it was installed was different than what the parameter was). > > > Probably not, but it is in /usr/include/firefox-1.5/mozilla-config.h, > so something else may depend on it on the macro. Needs more research. > I agree with you that it doesn't affect running firefox. How do we do this "research". I'll be happy to, but starting from scratch on this, I may not be able to find out too much. Perhaps for now we should just leave it in, but how do we describe it? What does it do? >>ac_add_options --enable-xinerama # dual display support >> >>(as best as I can tell this is on by default) > > No, ENABLE_XINERAMA is unset unless you pass in --enable-xinerama. I will certainly take your word on this. I was mistaken. I thought again it was something that about:config said was enable, but as I said, I was mistaken. Should it be enabled by default, or turned off with a comment to unremark it from .mozconfig if you want it? Thanks for the input, Dan. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 17:48:00 up 87 days, 3:12, 3 users, load average: 0.51, 0.31, 0.32 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
