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

#81 Post by Gedrean »

To clarify then, CXXFLAGS and CFLAGS should be the same value.

CFLAGS should be separated by spaces, with a leading space at beginning of string and a trailing space at end of string.

LDFLAGS should be separated by commas, with a leading space at the beginning, and a trailing space at the end.

Am I correct on all that?

EDIT:

Oh and did a little research, | needs to be escape-char'd in command line most of the time, or double-quoted, and the way we're wording things the odds that those chars will interfere are VERY low, so I think the | and & should work. \ will be a pain in the ass because I'd have to do a lot of \-escaping the \'s, so... I would want to kill myself after a while. :)

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

#82 Post by technosaurus »

Gedrean wrote:... I would want to kill myself after a while. :)
I hear you - I hate picket fences. That's what initially scared me away from learning bash.

correct
CFLAGS and CXXFLAGS can use the same parameters but need to be specified seaparately


LDFLAGS is passed with -Wl$v1$v2$v3$v4$v5$v6$v7$v8$v9$v10 \
each variable should contain a preceding comma followed by the actual flag and nothing after

cflags template

if [ $CB_CFPIPE = "true" ];then
CB_CFPIPE =" -pipe " #description of pipe...
else
CB_CFPIPE ="" #setting it back to "null" allows us to pass all parameters without doing more "if thens"
fi

ldflags template

CB_LDO
if [ $CB_LDO = "true" ];then
CB_LDO=",-Os" #description of pipe...
else
CB_LDO="" #set back to "null"
fi


CFLAGS="$CFLAGS$CB_CFPIPE$CB_CFCOMBINE....$CB_CFMARCH -mtune=i686 " \
CXXFLAGS=$CFLAGS \
LDFLAGS=" -Wl,-04$CB_LDO$CBLDRELAX....$CB_LDSTRIP " \
./configure .....
(putting the proper separators in the string prevents)
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

#83 Post by Gedrean »

technosaurus wrote:
Gedrean wrote:... I would want to kill myself after a while. :)
I hear you - I hate picket fences. That's what initially scared me away from learning bash.

LDFLAGS is passed with -Wl$v1$v2$v3$v4$v5$v6$v7$v8$v9$v10 \
each variable should contain a preceding comma followed by the actual flag and nothing after

ldflags template

CB_LDO
if [ $CB_LDO = "true" ];then
CB_LDO=",-Os" #description of pipe...
else
CB_LDO="" #set back to "null"
fi


CFLAGS="$CFLAGS$CB_CFPIPE$CB_CFCOMBINE....$CB_CFMARCH -mtune=i686 " \
CXXFLAGS=$CFLAGS \
LDFLAGS=" -Wl,-04$CB_LDO$CBLDRELAX....$CB_LDSTRIP " \
./configure .....
(putting the proper separators in the string prevents)
Okay. So the LDFLAGS should be -quote--space-"-Wl," then -O whatever then everything else, all separated by commas, space preceding -Wl and following last argument. Got it.

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

#84 Post by Gedrean »

Alright. I'm gonna reformat things some in the window stuff, and build it like that in pcomp_script - hopefully it's self-explanatory what I do, but basically I'm not going to have the script "know" what the flag values or words are SUPPOSED to be, but instead just derive them from the varnames passed back by gtkdialog.

This way if later we add other flags at are off or on, there requires no code changes, just window changes.

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

#85 Post by Gedrean »

Lacking other input, I'm going with DV for Dynamic Variable (I'm cheap and lazy) and 2-character Function Code, again acronyms.

DV|FC|StringToBeUsedInTyping="true" etc...
If false, don't strip the string.
If true, strip the string and put it in.

For example, in the instance of -fomit-frame-pointer...

DV|CF|-fomit-frame-pointer="true" -- hopefully that makes sense.
The building script should insert the separating spaces, commas, spaces in right locations, etc.
It should be smart about those parts.

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

#86 Post by technosaurus »

It took me a bit to figure out what you were saying but now that I got it, it sounds good. What you are talking about could be pretty useful for some other programs.
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

#87 Post by Gedrean »

I figured I'd post a code snippet, in case other programmers read and are interested (HAH! That'll be the day!)

Code: Select all

# This is a template of how we're doing it now.
# This template covers EVERY loop for Dynamic Variables.
# This template also details variable naming, for coding style purposes.
# For this template, <FC> means function code, 2 digit code from var names.

# First, we declare our holder for all codes of this DV type.
# Call it: "DV_<FC>_CODE"
# Strip out the leading = and perform a grep of "DV\|<FC>\|" from CHOOSER2
# and put the result in this holder.
# Declare another variable, DV_<FC>_REMAINING, equal to this first holder.
# Declare a third variable, DV_<FC>_RESULT, for storing the end result in.
# This RESULT MUST start out null ("").  NO starter value!
# In a while loop, condition: [ "$DV_<FC>_REMAINING" != "" ]
#	Set a name equal to the first "name" in REMAINING:
#	NAME=${DV_<FC>_REMAINING%%=*}
#	grep the NAME from the DV_<FC>_CODE and put result to ENTRY and VALUE.
#	Perform strip command: pcomp_strip VALUE $NAME -- VALUE not $-expanded!
#	if condition: [ $VALUE == "true" ]
#		( We could also use other conditions if value isn't going to be ...
#		a true/false, but that's more complicated )
#		Strip 'DV|<FC>|' from NAME: NAME=${NAME#DV\|<FC>\|}
#		Replace & with = in NAME: NAME=${NAME/\&/=}
#		Format and add NAME to the end of DV_<FC>_RESULT
#	fi
#	Remove ENTRY from REMAINING: DV_<FC>_REMAINING=${DV_<FC>_REMAINING#$ENTRY}
#	Remove leading space: DV_<FC>_REMAINING=${DV_<FC>_REMAINING/?DV\|/DV\|}
# done
# if condition: [ $DV_<FC>_RESULT != "" ]
#	Perform any additional formatting to result (add starter string) ...
#	and add to final exec string
# fi
As you'll note, this is a code template, not actual code - but it should give a proper idea of how to parse out dynamic values like this from gtkdialog in ANY instance, with a little interpolation...

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

#88 Post by Gedrean »

On a side note, you'll notice in the code snippet that I have the REMAINING variable simply for getting the "NAME" of the first entry from, and for stripping full entries from for the purposes of a really cheap counter
(I could do a for loop, now that I think of it, but I don't recall what happens with a for loop when passed an empty string-list, and I didn't want to code around with it, though I could definitely do that if it works... Hold on...)

As you may have noticed, during my massive rambling posts which don't make much sense to anyone, I tend to do posts on a train of thought, and rarely go back and delete stuff that is contradicted by later comments, trusting it will be taken like a conversation.

You'll now understand then, why I want to go cry in a corner. I spent nearly 4 hours trying to figure out why I couldn't just strip the value from the CODE variable.

I could have done it with a for loop.

It would have been easier.

None of that "stripping stuff out".

Anyhow.

Yeah. I'll post a later update with for loops.
God I feel like an idiot.

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

#89 Post by Aitch »

Hi Gedrean
I'm not a programmer, but I share house with one named Pat
He uses xbasic, so I can follow the logic, if not the vision....
I always admire people like You, Techno, Aragon, Patriot, disciple, amigo, tronkel, pizzasgood, 01micko, ttuuxxx, etc, etc.....
[to name a few of the top of my head - please don't write me if you weren't included,.... nothing personal... :D ]
...and enjoy watching communication of this tricky concept between 2 [and more] people, trying to resolve a programming problem.
I've lost count of the number of times Pat has had one of those 'Doh!' moments - you are not alone :wink: :)
....and your conversational style makes a good read...thanks....even if I'm unlikely to use it.... :lol:

Keep up the good work, and the inspiration to those who will use it :D

Aitch :)

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

#90 Post by Gedrean »

Okay, here a new template with FOR instead of While.

The template is much larger itself in text than the loop will be, because once this is documented only spot-comments will be needed for tricky lines.

Code: Select all

# This is a FOR loop template, much cleaner than before.
# First, we declare our holder for all codes of this DV type.
# Call it: "DV_<FC>_CODE"
# Strip out the leading = and perform a grep of "DV\|<FC>\|" from CHOOSER2
# and put the result in this holder.
# Declare a variable, DV_<FC>_RESULT="", for storing the end result in.
# This RESULT MUST start out null ("").  NO starter value!
# for COUNTER in DV_<FC>_CODE
#	Set a name equal to the name of the value in COUNTER:
#	NAME=${COUNTER%=*}
#	Set VALUE equal to COUNTER: VALUE=$COUNTER
#	Perform strip command: pcomp_strip VALUE $NAME -- VALUE not $-expanded!
#	if condition: [ $VALUE == "true" ]
#		( We could also use other conditions if value isn't going to be ...
#		a true/false, but that's more complicated )
#		Strip 'DV|<FC>|' from NAME: NAME=${NAME#DV\|<FC>\|}
#		Replace & with = in NAME: NAME=${NAME/\&/=}
#		Format and add NAME to the end of DV_<FC>_RESULT
#	fi
# done
# if condition: [ $DV_<FC>_RESULT != "" ]
#	Perform any additional formatting to result (add starter string) ...
#	and add to final exec string
# fi
Hope this is nicer. I haven't yet rebuilt any of the loop systems (so right now my pcompile copy is actually neutered) but they WILL be done sometime in the next 24-48. :) Soon's I get together a few free hours and the actual will to code. Exhausting day today, Rennaissance Festival was visited. :)

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

Post Reply