Compiler GUI and other packaging tools

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

#91 Post by Gedrean »

Alright, I have completed the loop for Configure Options.

Code: Select all

DV_CO_CODE="`echo "${CHOOSER2#=}" | grep DV\|CO\|`"
# DV_CO_CODE should have the list of all Config Options DV's
DV_CO_RESULT=""
for COUNTER in $DV_CO_CODE
do
	NAME=${COUNTER%=*} # Get everything on the left side of the =.
	VALUE=$COUNTER
	pcomp_strip VALUE $NAME # Now we have the value.
	if [ $VALUE == "true" ]; then
		NAME=${NAME#DV\|CO\|} # Strip the DV/CO indicator
		NAME=${NAME/\&/=} # Replace & with =
		NAME=$NAME" " # Format to include trailing space
		DV_CO_RESULT=$DV_CO_RESULT$NAME # Stick it together
	fi
done
Looks good to me, runs good too! :) And nice and short too!

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

#92 Post by Gedrean »

Okay new questions.

I've got some concerns, one of these CFLAGS has an =2 and the other just has a 2, I'm not sure if these flags are exactly as you want them or not. For now, whatever's in the label is EXACTLY how it's getting pushed to the configure command line, so if you go through there and notice some arguments are wrong, they need to be fixed up.

Second, Optimization and Architecture - those are part of CFLAGS?

Third, should -O4 and -Os in LDFLAGS be together?

Also, the commas aren't gonna be in the label, they will be in the string overall, but thanks for the reminder.

Given that, I'm assuming Arch and Opt go to CFLAGS, and coding for that for now.

I like the user-defined sections.

I'm going to try and separate LDFlags and CFlags -- I'm not against a fourth tab, and I think the flow and spacing will work better, as it is CFlags has those three sets of args that are two-column instead of one, and they don't line up well -- admittedly gtkdialog has HORRIBLE layout options, so I'm gonna see just what I can make work to make everything look nice.
--That should also make the window a bit smaller -- it was smaller before, and while bigger isn't terrible, if we're pushing for Lowest Common Denominator I'd want to assume we're working with maybe an 800x600 screen at worst, maybe even 640x480, and so smaller is better if possible.

I don't think it's going bad though.

Keep up with it here, we're getting to a finish line and a release I think for v2. At this point we should release a v2 before moving on to further changes and alterations -- as it is the script code is nice and lean, I've stripped out a lot of things that aren't necessary... commented still but tried to get nicer.

So get back to me on those flags questions, and we'll see what we can pump out. :)

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

#93 Post by technosaurus »

they are correct:
mpreferred-stack-boundary is looking for a power of two - in this case 2^2

the other fbranch... tells gcc to optimize branches toward the end after a bunch of other optimizations have been done

,-O4,-Os is a really hacky way of ensuring that the code size doesn't accidentally get increased... when linking gcc is supposed to look for -O, but there are plans to add the option of a numerical value (like -O[0-9]) so using -O4 prevents accidental generation of large and often broken -O3 bytecode and the subsequent -Os is there for the same reason. With Puppy's current gcc ,-O4,-Os is no different than using ,-O

btw gcc 4.4.2 is out now. I may build that later today while I am on a long car trip to go hiking with the family. It would be good to test the options on older and newer versions. I also have gcc 3.4.6 statically compiled against dietlibc to see how backward compatible it is.
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:

#94 Post by technosaurus »

I worked on dump2 pet (renamed to possibly keep backward compatibility via a check of /etc/puppyversion > 425)
Attachments
dmp2pet.gz
(2.09 KiB) Downloaded 370 times
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

#95 Post by Gedrean »

There's an incredibly easy solution to the backwards compatibility:

Have dump2pet be a wrapper that checks puppyversion and calls one of two scripts in the usr local pcompile directory depending on result.

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

#96 Post by Gedrean »

technosaurus wrote:btw gcc 4.4.2 is out now. I may build that later today while I am on a long car trip to go hiking with the family. It would be good to test the options on older and newer versions. I also have gcc 3.4.6 statically compiled against dietlibc to see how backward compatible it is.
Maybe something good to suggest BarryK update in the next devx revision.

EDIT: Or, since you're doing 4.4, you could update it for that. :)

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

#97 Post by technosaurus »

Barry is now working directly on woof & I am coordinating 4.4 CE, so it will definitely be in that. The biggest reason I started working on this was to make it easier for package maintainers, including myself, to update packages. We don't have a whole lot of "package maintainers" so another goal was to make it easy for beginners and intermediate users to contribute. I think we are getting there.

As for dump2pet / dmp2pet they could be part of the same script with the check builtin or separate scripts with the check in pcompile itself. The only thing I did not set up was a check for the specific distro for woof compatibility (to determine if it should be puppy, debian, slack ubuntu or arch) I just need to figure out where that info is... probably in a file in /etc
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

#98 Post by Gedrean »

True, they can also be in the same script, as a whole function for each would work well to separate the code and make them easy to read.

If there are certain output functions that are needed, like gtkdialogs, it's possible to have it gtkdialog a single quote through a function... hmmm now I wanna see how THAT would work... Damn gotta keep off the side stuff. :)

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

#99 Post by technosaurus »

should not need any dialogs. thats the whole reason I made dump2pet in the first place ... so that DEV DOC and NLS didn't waste so much time... the main pet will still call dir2pet which has its own dialogs.

I may update dir2pet as well so that all of the automatic stuff is done, a single dialog is brought up and then all the changes are made (again to avoid all the extraneous dialogs)

I also have dmp2pet writing the package database entry to ~/.pcompile.pets (I used the tilda for future multiuser compatibility) I would especially like to have the main package entered into that file as well

.... hmmm maybe I should have the defaulttextviewer open that instead. My whole reasoning behind this is that petspecs always puts the file in the same location with the same name and Nicoedit likes to forget the last entry when this happens, which would cause us to lose track of the db entry.
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

#100 Post by Gedrean »

So to have dir2pet do it all in dialogs instead of in the command prompt would be nice - since instead of doing that "type a character and hit enter" crap it's just got dialog box with entry boxes if needed, and maybe a separate tab for the ".desktop" entry... oooh I smell awesome... (in that this will be so awesome I can already smell it!)

And the package database entry stuff? Well... I have no clue about all that yet, so that'll be your area of expertise :)

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

#101 Post by Gedrean »

Oh, and if you can, and it's convenient enough, could you give me, through all these CFLAGS in the first box there in your previously posted screenshot, a classification, like what they're for? Or maybe group them into two or more groups, in terms of what they're used for? I'm trying to figure out how I can nicely restructure out the CFLAGS list so it takes up less room wide and tall, and get all those CFLAGS groups together, then do the same for the LDFLAGS... it's mostly for layout purposes, I can try to make up something on my own if needed...

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

#102 Post by Gedrean »

By the way, what is -Wl in LDFLAGS? Is it always going to be included?

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

#103 Post by Gedrean »

Hey, look! A needlessly long code post!

Code: Select all

# Parse Dynamic Variables - Config Options 
DV_CO_CODE="`echo "${CHOOSER2#=}" | grep DV\|CO\|`"
# DV_CO_CODE should have the list of all Config Options DV's
DV_CO_RESULT=""
for COUNTER in $DV_CO_CODE
do
	NAME=${COUNTER%=*} # Get everything on the left side of the =.
	VALUE=$COUNTER
	pcomp_strip VALUE $NAME # Now we have the value.
	if [ $VALUE == "true" ]; then
		NAME=${NAME#DV\|CO\|} # Strip the DV/CO indicator
		NAME=${NAME/\&/=} # Replace & with =
		NAME=$NAME" " # Format to include trailing space
		DV_CO_RESULT=$DV_CO_RESULT$NAME # Stick it together
	fi
done
CFGOPTS=$DV_CO_RESULT$UCONFIG
# Now we have all the results, a final trailing space, and UCONFIG.
# This also works if either or both are empty.

# Parse Dynamic Variables - C/CXX Flags
DV_CF_CODE="`echo "${CHOOSER2#=}" | grep DV\|CF\|`"
# DV_CF_CODE should have the list of all CFlags DV's
DV_CF_RESULT=""
for COUNTER in $DV_CF_CODE
do
	NAME=${COUNTER%=*} # Get everything on the left side of the =.
	VALUE=$COUNTER
	pcomp_strip VALUE $NAME # Now we have the value.
	if [ $VALUE == "true" ]; then
		NAME=${NAME#DV\|CF\|} # Strip the DV/CF indicator
		NAME=${NAME/\&/=} # Replace & with =
		NAME=$NAME" " # Format to include trailing space
		DV_CF_RESULT=$DV_CF_RESULT$NAME # Stick it together
	fi
done
# Leading and Trailing space in CFLAGS/CXXFLAGS string will be done when ...
# we build the string right before running ./configure
CFLAGS=$DV_CF_RESULT$UCFLAGS
# Now we have all the results, a final trailing space, and UCFLAGS.
# This also works if either or both are empty.

# Parse Dynamic Variables - LD Flags
DV_LD_CODE="`echo "${CHOOSER2#=}" | grep DV\|LD\|`"
# DV_LD_CODE should have the list of all LDFlags DV's
DV_LD_RESULT=""
for COUNTER in $DV_LD_CODE
do
	NAME=${COUNTER%=*} # Get everything on the left side of the =.
	VALUE=$COUNTER
	pcomp_strip VALUE $NAME # Now we have the value.
	if [ $VALUE == "true" ]; then
		NAME=${NAME#DV\|LD\|} # Strip the DV/LD indicator
		NAME=${NAME/\&/=} # Replace & with =
		NAME=$NAME"," # Format to include trailing comma
		DV_LD_RESULT=$DV_LD_RESULT$NAME # Stick it together
	fi
done
# Leading and Trailing space in LDFLAGS string will be done when ...
# we build the string right before running ./configure
LDFLAGS=$DV_LD_RESULT$ULDFLAGS
# Now we have all the results, a final trailing comma, and UCFLAGS.
# If however UCFLAGS was empty, we do need to strip that trailing comma.
if [ $ULDFLAGS == "" ]; then
	LDFLAGS=${LDFLAGS%,}
fi
# Now the LDFLAGS has either a properly formatted list, or nothing.
That's the loops code to extract everything from LDFLAGS, CFLAGS, and CONFIG OPTIONS... :)

Make sure if any vars are reused inappropriately, if you see something, say something! :)

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

#104 Post by Gedrean »

Okay, tried to build SDL which seemed to work fine with the original defaults, with the new "defaults" in the window file, and got the following error in a config.log:

Code: Select all

configure:2072: gcc  -Os -combine -fmerge-all-constants -fomit-frame-pointer -march=i386 -momit-leaf-frame-pointer -mpreferred-stack-boundary=2 -mtune=i686 -pipe    --no-keep-memory,--sort-common,-O4,-Os,-relax,-s  conftest.c  >&5
cc1: error: unrecognized command line option "-fno-keep-memory,--sort-common,-O4,-Os,-relax,-s"
EDIT: I forgot to put in the -Wl, so I can't continue till the question about -Wl that I raised in a few posts back:

By the way, what is -Wl in LDFLAGS? Is it always going to be included?

Is answered.

EDIT2: So I stuck -Wl hardcoded into the LDFLAGS code -- it seems happy.

I think that -Wl must be what tells gcc or whatever that the LDFLAGS are LDFLAGS... :)

Anyhow, let us be happy that it works, work on a bit of cleanup of the interface (it just feels so bad)...

All I need now is that categorization of the CFLAGS, any other categories they fit into would be great to separate them out if possible. If not, I'll tool around with the window code for formatting concerns, trying to make it all look even...

But I think this is good for a 0.2.0 release.

Works for either one you want to build too, woof or upup or ppup or whatever...

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

#105 Post by technosaurus »

Sorry, misunderstood the question. -Wl is required to pass parameters to the linker using the comma separate values, so it is always included in LDFLAGS


All of the CFLAGS are here
http://gcc.gnu.org/onlinedocs/gcc-4.2.4 ... ze-Options

The defaults are to decrease code size, while the rest sometimes help make the program either start faster or run faster

LDFLAGS are not well documented
--gc-sections should be used with -ffunction-sections and -fdata-sections to "garbage collect" the unused ones (putting them in sections makes it easier for them to find) but using it on shared libraries can break things - so they should only be used for programs.

-no-keep-memory (not -fno-keep-memory) tries to save memory by having more disk read/writes where memory writes aren't necessary - this works well with the way Puppy is installed since Full installs are typicall of low ram machines and Frugal installs are typically loaded into RAM already so its not much of an issue there

--as-needed is one of those that I wish we could always use because it allows faster startup but some programs (Nicoedit for one) do not work with that flag... it doesn't load all of the shared libraries until they are needed

the `-relax' option performs global optimizations that become possible when the linker resolves addressing in the program, such as relaxing address modes and synthesizing new instructions in the output object file

-sort-common - Normally, when ld places the global common symbols in the appropriate output sections, it sorts them by size. First come all the one byte symbols, then all the two bytes, then all the four bytes, and then everything else. This is to prevent gaps between symbols due to alignment constraints. This option disables that sorting.

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
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

#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.

Post Reply