Sharing your Compiling Configurations

What features/apps/bugfixes needed in a future Puppy
Post Reply
Message
Author
User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

Sharing your Compiling Configurations

#1 Post by Tman »

I've been doing some compiling here and there for a couple of months now and wish for a system where compiled configurations for pets can be easily shared amongst compilers.

Yes, there is the "Compiling" section in this forum, but if one goes there, you will find that there is only currently 2 pages of info in that thread, compared to the plethora of pets that have been compiled for Puppy. There were a few instances, while reading the forum I came across a message similar to: "The pet was compiled by ...so and so, but we cannot tell what compiling options he (or she) used."

Without knowing these compiling options, for the previously (well-built) pet, it leaves other compilers with the task of:
- doing the research, looking at all of the availiable compiling options
- enabling and disabling various compilation options

This is basically re-inventing the wheel.

While this process is great when you are starting out and learning, after time it becomes a chore.
And considering the amount of linux apps out there, I see this as incredible waste of time.
I think that if we adopted some sort of system, where compilers share their options/techniques, productivity for the entire community would be increased, as we wouldn't be spending so much time re-inventing the wheel.

So, by what method(s) can we adopt to encourage sharing of this information? Please see the next post...
Last edited by Tman on Sun 29 Apr 2012, 18:24, edited 1 time in total.

User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

#2 Post by Tman »

I propose for compilers who are interested, to place their compiling options/configurations inside of the pinstall.sh scripts of their pets.

Example #1:
here is the pinstall.sh code for my dillo-3.0.2

Code: Select all

#!/bin/sh
Xdialog --beep --center --title "Setup" --yesno "Do you wish to make Dillo the defaultbrowser?" 0 0
if [ $? -eq 0 ];then
defaultBR=/usr/local/bin/defaultbrowser
[ ! -f $defaultBR-old ] && mv -f $defaultBR $defaultBR-old
echo "#!/bin/sh
exec dillo \"\$@\"" > $defaultBR
chmod 755 $defaultBR
fi
By adopting the new method, it would be something like this:

Code: Select all

#!/bin/sh
#Tman - compiled in Exprimo 5.X.13.5 as follows:
# src2pkg -VV -e='--sysconfdir=/etc localstatedir=/var --docdir=/usr/share/doc/dillo --enable-ssl=yes --enable-ipv6=yes --with-jpeg-lib=/usr/lib' dillo-3.0.2.tar.bz2
# Added Dependencies: fltk-1.3.x
#
#
Xdialog --beep --center --title "Setup" --yesno "Do you wish to make Dillo the defaultbrowser?" 0 0
if [ $? -eq 0 ];then
defaultBR=/usr/local/bin/defaultbrowser
[ ! -f $defaultBR-old ] && mv -f $defaultBR $defaultBR-old
echo "#!/bin/sh
exec dillo \"\$@\"" > $defaultBR
chmod 755 $defaultBR
fi
Example #2 - Firefox-12.0 pinstall.sh

Code: Select all

#!/bin/bash
# Tman - compiled in ...pup  with:
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --disable-dbus --disable-libnotify --enable-shared --disable-static --disable-debug --disable-crashreporter --disable-tests --disable-xinerama --disable-gnomevfs --disable-gnomeui --enable-safe-browsing --disable-accessibility --disable-logging --enable-strip --disable-necko-wifi --enable-application=browser --disable-warnings-as-errors
# Added Deps: Yasm-1.2.0
#
#
# ask to remove old firefox settings
configDIR=/root/.mozilla/firefox
if [ -d $configDIR ]; then
  Xdialog --center --title "Setup" --yesno "Remove previous Firefox saved settings?\n( Recommended , but your bookmarks will also be removed )" 0 0
  [ $? -eq 0 ] && rm -rf $configDIR
fi
I could go a step further and add the url for the source, to make it easier to find.
-
Last edited by Tman on Sun 29 Apr 2012, 18:26, edited 4 times in total.

User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

#3 Post by Tman »

Benefits
- with an extra few bytes of text, we have included very important info that will always remain with the pet and not get lost
- others stuck on compiling that particular app can refer to this info
- you can view other people's compilation options for pets in which you couldn't compile successfully
- you can make various pets with different options, and test out which compiles smaller, more stable ..etc and with the options included inside of the pet, you can refer to them, if you get confused as to which options you enabled and/or disabled.
- when installing the pet,it doesn't take up any extra space inside of the filesystem
- in the long run, it will save compilers time when the information is shared
- others may be willing to help more with compiling, leaving you more time to do other things
- even noobs can start contributing, as long as they know how to make a pet

Drawbacks
- when the pets are processed by woof, the compilation options/settings won't be found in the distro
- it takes a little bit of extra time
- more experienced members may laugh at your puny compiling skills :oops: :)

For example, please see this post in Barry's Blog: http://bkhome.org/blog/?page=1
Well I would love to help you Barry, I would, but those are a lot of apps; most of which I've never compiled before. Lets say I go through the trouble of compiling some and getting them to work...but I used less optimal settings than you did; would you be pleased with that? hmmm. If I had your exact setttings, then I that would take the guess work out of it and, I could get more apps compiled.
Do you guys see my point?

What do you compilers think? Do you think that it is a good idea to adopt this new method, I am proposing?
-

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#4 Post by jemimah »

No one will do it if it has to be done manually.

Something like this added to new2dir would be better.

Code: Select all

if [ -f config.log ] ; then
   mkdir -p "${EXE_TARGETDIR}/usr/share/doc"
   head config.log >  ${EXE_TARGETDIR}/usr/share/doc/${EXE_PKGNAME}.config
fi
This obviously only works for automake. It could probably be extended to work with other tools.

Barry would need to make this change to if is is to catch on.

User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

#5 Post by Tman »

Jemimah,

Automating the task would be even better. The Puppy name and version that the software was compiled in, could be collected from /etc/DISTRO_SPECS. The only drawback I see by putting it in the /usr/share/doc folder is that non-compilers would see all of these documents as extra bloat..I think putting the automated files in the devx.sfs would be good. I have privately messaged Barry about this, but he hasn't read it yet.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#6 Post by amigo »

Tman, you are using src2pkg, so why not just use, save and share your src2pkg script -you can't get much more universal and explicit than that.

User avatar
chrome307
Posts: 708
Joined: Thu 15 Jan 2009, 11:00

#7 Post by chrome307 »

I think it would be a great idea and it would encourage people to get to understand their OS better and give them some confidence in creating new applications that can be shared with others.

I've only started compiling myself and have been encouraged that others have used some of the applications I have uploaded.

From memory I think I asked DPUP for some instructions and was given the basic information I needed.

Whichever method is used, I think it would a positive step forward.

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

Re: Sharing your Compiling Configurations

#8 Post by sc0ttman »

Tman wrote:Yes, there is the "Compiling" section in this forum, but if one goes there, you will find that there is only currently 2 pages of info in that thread, compared to the plethora of pets that have been compiled for Puppy.
It's probably because of 2 things - lack of interest in sharing to beginners, and because the compiling section still does not allow users to edit their own posts - which is annoying... I PM'd the admins about it, but nothing changed...

I agree with jemimah about new2dir, although not everyone compiling for puppy knows or uses new2dir - I didn't at first, until I wanted to know how to easily split into DEV, NLS, DOC pkgs...

Maybe Barry should look into integrating something like that into Woof - then the vast majority of pkgs will have a corresponding .config in /usr/share/doc/ next time he builds a Puppy... It's a real quick way to jump forward and make some progress in this area..
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

#9 Post by Tman »

Thanks Everyone for your feedback,

I think Jemimah is right; Barry would need to itegrate this somehow for it to become popular. If a savvy coder could create an automated routine, I am sure others would be more eager to share their settings.

The only problem is that there are different methods to compiling and the difficult task would create a package that can encompass these different methods.

I think that keeping the compiling options inisde the pet is the best place for them not to get lost. The compiling section is good if you need to ask others for more advanced help.

In the meantime, I think I will add them manually to the future pets that I create. But I will place them in the /usr/share/doc/dev folder instead of the pinstall.sh.
My reasoning is that maybe if I start doing it, some others do so as well. There are so many apps to compile out there. I just don't see the sense of everyone trying to figure out the .configure options for each app, independently each time.

I figure if I do this, then I will save time for other compilers and, hopefully vice-versa. The accumulated saved time is potentially enormous.
Tman wrote: Well I would love to help you Barry, I would, but those are a lot of apps; most of which I've never compiled before.
Does the statement above come across as being somewhat rude? If so, it wasn't meant to be: I respect Barry very much.

Post Reply