Compiler GUI and other packaging tools

Stuff that has yet to be sorted into a category.
Message
Author
User avatar
Gedrean
Posts: 139
Joined: Fri 05 Jun 2009, 05:59

#106 Post by Gedrean »

technosaurus wrote:All of the CFLAGS are here
http://gcc.gnu.org/onlinedocs/gcc-4.2.4 ... ze-Options
So, are the options you put in the window dialog all of those then?
LDFLAGS are not well documented
Of course not.
The gui dialog was a good idea too, the terminal dialog has been bugging me for a while since it is in a somewhat backgrounded terminal and can go unnoticed
Yeah, that's about how I feel.

User avatar
Gedrean
Posts: 139
Joined: Fri 05 Jun 2009, 05:59

#107 Post by Gedrean »

Alright, finding no immediate classifications or categories I can really split them into, I find myself needing to organize them by certain spacings, trying to group certain sets together for optimal space concerns.

Other than alphabetics or the order you found them in, is there a specific reason for their current order? If they're out of order it won't be like "oh these should go together because they focus on the same things or some depend on others being already turned on"?

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

#108 Post by amigo »

'man ld' will telly ou about the options.

I'll give you a tip, just use the most generic options for the best, most univresal results -especially with CFLAGS. Use -Os for small size, -O3 for faster(but larger) and -O2 for widest compatibility. These settings let gcc itslef help you by figuring out what is best. If you start being specific with -fomit-frame-pointer etc, you'll just wind up creating binaries which run on less hardware -for instance, many of those flags you want to use are incompatible with AMD processors. You can add -pipe and -combine as they speed up compile times without changing the bins. fo LDFLAGS, all you really need to spcecify is -L/path/to/libs and -staic for staically linking binaries when(rarely) wanted. I have a program (src2pkg) which ahs been doing these things for a few years now and has *lots* of users, and I found out that the fancier youz try to be, the less people its' gonna work for. And giving your users a bunch of ways to change these options is just gonna confuse them. for (really) advanced users, leave a way for them to configure these options from the command-line or from a conf file. the best way to allow command-line configuration is to simply do nothinga nd let them pass these flags as environmental variables. Anyone who knows how they work/what they do, will be most comfortable with that anyway.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#109 Post by technosaurus »

as far as ordering the only thing that I am certain of is that if you specify two opposite flags then the latter one will be used (for example if you specify -fno-PIC and later -fPIC then it will be compiled with Position Independent Code)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Gedrean
Posts: 139
Joined: Fri 05 Jun 2009, 05:59

#110 Post by Gedrean »

amigo wrote:'man ld' will telly ou about the options.

I'll give you a tip, just use the most generic options for the best, most univresal results -especially with CFLAGS. Use -Os for small size, -O3 for faster(but larger) and -O2 for widest compatibility. These settings let gcc itslef help you by figuring out what is best. If you start being specific with -fomit-frame-pointer etc, you'll just wind up creating binaries which run on less hardware -for instance, many of those flags you want to use are incompatible with AMD processors. You can add -pipe and -combine as they speed up compile times without changing the bins. fo LDFLAGS, all you really need to spcecify is -L/path/to/libs and -staic for staically linking binaries when(rarely) wanted. I have a program (src2pkg) which ahs been doing these things for a few years now and has *lots* of users, and I found out that the fancier youz try to be, the less people its' gonna work for. And giving your users a bunch of ways to change these options is just gonna confuse them. for (really) advanced users, leave a way for them to configure these options from the command-line or from a conf file. the best way to allow command-line configuration is to simply do nothinga nd let them pass these flags as environmental variables. Anyone who knows how they work/what they do, will be most comfortable with that anyway.
That's really odd, I use an AMD and most of the stuff in PCompile has run on mine. Which flags are you referring to amigo?

And I'm aiming to make it so that the average user is instructed to stick to the first two tabs or less, as the CFLAGS/LDFLAGS options are mainly there for maintainers to choose certain options as needed without having to type them in, just go to the tab, check if it's there, if not type it in, if it is check or uncheck it, and move on.

Most of the defaults are, as techno said, designed to work 99% of the time to make the code smaller and faster at a good ratio to each other, since we're usually dealing with old and small computers here.

Besides, it's fun!... okay I'm lying, I hate layout design, but it's not like getting teeth pulled, plus it leads to coding, which to me IS fun.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#111 Post by technosaurus »

Amigo's src2pkg is a really useful tool and great for building a majority of packages. I had initially planned to use it as the backend of Pcompile, but wanted something a bit simpler that a new user would not get overwhelmed by but an advanced user could still use in their toolbag. I hope that it will be a useful learning tool to help with bringing the beginners to that advanced level. How many times do we see on the forums ./configure, make, makeinstall or for pets ./configure, make, new2dir makeinstall. Nobody ever takes that extra step to explain anything further (aside from the occasional ./configure --help)

btw -fomit-frame-pointer is enabled by default on most optimization levels.

speaking of configuration files ... since we are storing all the variables it is a small step to echo them to a file (we are already writing the package db entry to ~/.pcompile.pets <-subject to change to a directory if we will be writing more than one file)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Aitch
Posts: 6518
Joined: Wed 04 Apr 2007, 15:57
Location: Chatham, Kent, UK

#112 Post by Aitch »

technosaurus wrote:How many times do we see on the forums ./configure, make, makeinstall or for pets ./configure, make, new2dir makeinstall. Nobody ever takes that extra step to explain anything further (aside from the occasional ./configure --help)
thank you!

I thought it was just me ....

Aitch :)

User avatar
Gedrean
Posts: 139
Joined: Fri 05 Jun 2009, 05:59

Almost Done...

#113 Post by Gedrean »

It is almost completed, at least as far as I'd suggest for 0.2.0.

I have not been able to test extensively just how much it does or does not do.
It has successfully compiled SDL, SDL_Image, and SDL_Mixer.

I've not had to compile any applications lately...
so I'm going to try right now, to compile something.

Tried to compile something - found out an annoying glitch in dir2pet.

See, dir2pet clears the screen before beginning, so it can get its formatting all nice.

Problem with that: With our rxvt orange box terminal which looks so cool, that clear kills about a screen's worth of output from the compile or make -- such as error messages.

The problem then is how to make sure those error messages get saved in some way before dir2pet nukes them.

Is there some way to insert a whole blank screen, the entirety of whatever one's terminal window size is? That would jump the text enough that clear should not kill the screen.

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#114 Post by 01micko »

technosaurus wrote: How many times do we see on the forums ./configure, make, makeinstall or for pets ./configure, make, new2dir makeinstall. Nobody ever takes that extra step to explain anything further (aside from the occasional ./configure --help)
If I compile something (lately) I make it a habit to post my "./configure" options if I post the pet. (THIS SHOULD BE COMPULSORY!) This is a good way to tell the more experienced around here what you did. Perhaps, with the pcompile gui that should be a default, ie, save a text file of the configure options within the .pet , considering that this is designed for relative newbys

I have used src2pkg, using SlaxerPup and I thought it was cool. I have tried to use it with mozilla source (compile Firefox or Seamonkey) but it failed, but this was about six months ago and it was a version big_bass posted ... I'll get back on the version.

Nice work here... cheers.
Puppy Linux Blog - contact me for access

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

#115 Post by amigo »

To compile mozilla with src2pkg, you need to copy in a .mozconfig file or pass a whole bunch of config options.
As far as simplicity, you can't beat src2pkg. More than 80% of what you try to compile and package will be as simple as this:

src2pkg name-of-tarball
or:
src2pkg url-of-tarball
You can't get any simpler than that. And it knows how to handle about 18 different kinds of sources: autoconf, imake, jam, scons, cmake, three kinds of perl modules and so on. Plus it checks for and/or corrects hundreds of common errors in packages like wrong perms, misplaced files/dirs, etc.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#116 Post by technosaurus »

another reason to rewrite dir2pet - yay! I can try to work on that tonight - I have a busy day today so not sure when I can get to it.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Gedrean
Posts: 139
Joined: Fri 05 Jun 2009, 05:59

#117 Post by Gedrean »

Alright, after LOTS of problems compiling different apps because of various nondescript errors (like expected <blah,blah,blah> before <this>) in some programs' makes, I managed to get Transmission to compile as a pet -- is there anyone not currently using or having it installed that would be willing to test it? I can't, I've already got it installed and would hate for it to get wrecked by this pet. <G>

Tried to find something I hadn't been running but EVERYTHING I try to compile application-wise has been failing with errors. I tried one app, and it bitched about libtool, so I install the newest libtool, and boom same problem. Tried another app, it needed some library installed, tried to do that library, it had its OWN dependency list.

I swear to god once Karmic Ubuntu works I'm gonna grab Woof, learn it, and build me a puppy with all the newest libraries and dependencies built in!!!!!! Argh!

User avatar
Gedrean
Posts: 139
Joined: Fri 05 Jun 2009, 05:59

#118 Post by Gedrean »

Alright, did manage to compile newest wget, it installs to /usr/bin -- here's my concern.

After the build was complete I found the files in the right directory in my build directory, but also they were already installed.

How does 2dirs work? Does it create an environment where everything in the prefix is prefixed by the directory for the pet dirs? Or does it let everything install then copy things out of there to put into the right directories?

User avatar
Gedrean
Posts: 139
Joined: Fri 05 Jun 2009, 05:59

#119 Post by Gedrean »

Well anyhow, app compiles are working, and those apps run with the defaults on an AMD Athlon XP 2400+ - so I think that's a good call there.

I'd say other than 2dirs letting programs install while trying to build a pet, and dir2pet's clear screen behavior, this is all good. :)

User avatar
Gedrean
Posts: 139
Joined: Fri 05 Jun 2009, 05:59

#120 Post by Gedrean »

Alright, nevermind, 2dirs behaves almost exactly like new2dir - without the questions. That's sad. I was hoping for some kind of "capture" where it captures writes and puts them elsewhere. Hmmm, maybe there's a way to do that...

User avatar
Gedrean
Posts: 139
Joined: Fri 05 Jun 2009, 05:59

#121 Post by Gedrean »

well, finding no solution I must be content with that behavior.

See if we can't clean up dir2pet some and we'll see what to do...

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#122 Post by technosaurus »

by capturing writes did you mean something like

Code: Select all

dump2pet [directory] > file
or is it?

Code: Select all

dump2pet [directory] 2> file
I think stderr and stdout require different > to print to a file.

I'll look at dir2pet as well - should be minor modifications to eliminate the issues. Probably just use Xdialogs unless I can figure out a way to get it to use a single gtkdialog effectively.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#123 Post by technosaurus »

the way the pet directories are made .... the files are "watched" as they are installed and then copied to the appropriate directory. This is probably the best way to do it since only some programs support a --destdir= parameter
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Gedrean
Posts: 139
Joined: Fri 05 Jun 2009, 05:59

#124 Post by Gedrean »

Yeah that's what I basically meant.

Oh well, no problem. Give dir2pet a bit of a makeover in Xdialog (I haven't yet figured out how THAT works) and we'll call it 0.2.0 ?

EDIT:

I sorta meant having make install not actually install the program, but it's okay.

At this point just make dir2pet do its stuff in Xdialog instead of to stdout.

Maybe name it something else, and include it with our tool, so the original dir2pet remains for those who prefer stdout to Xdialog. For now we'll indicate that, and if dir2pet as a script gets overall adopted as a different way we aren't stepping on someone else's toes, I'd think. But that's up to you since you're doing this and 4.4, so you make the call on that.
Last edited by Gedrean on Tue 20 Oct 2009, 21:14, edited 1 time in total.

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

#125 Post by amigo »

2 is stderr, 1 is stdout. You can redirect both at once like this:
command &> log.txt

Post Reply