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

#61 Post by Gedrean »

technosaurus wrote:Actually I only did a simple fix - use $1 $2 and $3 as before, but use them to set the default values, if you use it the same as src2all and all is good just click OK and you get the same behavior. I did have to set up a slightly different case for when there were no entries. The only difference is that there is a GUI there that will let you make some quick changes in a more readable interface before you let it go through the hours long process of compiling Wine-2.0 or whatever without NLS or some other useful feature because of a typo or something.
LOL I got the last part but for some reason my mind just jellied on the middle.

This was for dump2pet right? Listen if you want I could integrate src2all into pcompile - it's not hard and would serve some benefit as I said earlier. How's the other stuff feel/look?

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

#62 Post by technosaurus »

integrating src2all will allow things like equal signs and quotes to be passed more easily, since echo strips them out unless you use escape characters and -e (with a preceding \) as well as specifying the busybox echo... for whatever reason just echo -e didn't seem to work even though it is a link to busybox but...

Code: Select all

busybox echo -e
does work


All I was saying was that you could still enter the values from the command line ... it would just pop up the dialog to confirm and allow you to modify any typos 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

#63 Post by Gedrean »

Ohhhhhhhh! Well then have you done any? cause if not I'll just integrate it right now and post a new copy. I've been DYING to find that out!

And echo shouldn't strip out those... I'll check...

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

#64 Post by Gedrean »

Hmmm, a whole new problem.

It appears that calling a separate file has introduced something unpleasant... the gtk-file and gtk-open dialogs aren't triggering.

I don't honestly know why, so I'm trying it with the dialog copied back in as a single-quoted string (rather than double so I don't have to escape-quote everything)...

EDIT:

Had to doublequote and escape-quote...
BUUUUT...

It's still not calling the gtk-file and gtk-open anymore...

This is very odd.
The original pcompile I still have installed in /usr/bin - with its "already included" line instead of checkboxes... works fine.

I wish I knew when the problem was started... huh... wait I know.

Nevermind, false alarm.
I forgot to change a variable name in there one location... duh.

Okay ignore that. I'm gonna get back to what I was doing, testing echo losing = signs.

Just tested with new version...
It was the sed = thing that was stripping the = signs. Echo isn't losing the = signs, it works fine with my version. But I do agree at this point that it won't hurt to integrate anymore, especially given the ease of variable passing.

Here, unless any changes are made to src2all, I'll post in a new version with src2all still present but pcompile having src2all integrated (for testing).

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

#65 Post by Gedrean »

Some changes had to be made here and there.

Notably, with the integration of src2all, the orange stdout box disappeared.

So, I made the pcompile command merely a wrapper, that calls the real script, located in /usr/share/pcompile, as pcomp_script

The other commands (dump2pet and 2dirs) remain in /usr/bin alongside the newly shortened pcompile.

As well, in the actual script, I made a few changes in how it works to clean up code execution and reduce speed loss.

Instead of doing 7 (!) greps to find out what file it is, I did an extension trim and a case statement.
Inside, to ensure correct extensions, there is one grep per case for 3 out of the 4 possible results -- greatly reducing the number of greps that may result.

In addition, an invalid package type will output an error message and exit the program with an error code 1.

Only running into a small snag here...
Trying to put the results of ./configure --help into a variable (I'm trying to output the contents to a variable then to a file, so as to not re-read from the file, and output the contents to another file at another location) ...

Tried using eval CONF_OUTPUT="./configure --help" and getting nothing.

If I backtick it it tries to execute every line of the output of ./configure --help - which is even more than less than unhelpful. ;)

How could I do it?

EDIT:

Doing eval CONF_OUTPUT="./configure --help" gives "--help command not found"... doing it with backticks I get EOF errors looking for matching single quote (').

Nothing I find online seems to do what I want <G>

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

#66 Post by Gedrean »

Got it to take the value into the var -- with just `./configure --help` -- backticked command anyhow.

However, if I echo the variable to stdout, it shows with newlines and all just fine, all pretty.

If I output it to the file the way I had been up until now, it comes out without the newlines - everything all stacked on one line.

The other parts of the variable do come out nice and readable though.

I'm off to go somewhere for the evening, but if anyone has ideas it would be awesome, because this is about what's got me clogged up at this point -- I think the rest of the file works fine.

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

#67 Post by Gedrean »

After a lot of struggling, I solved my problems on my own. Turns out I was stingy with my double-quotes. Adding a few here and there made it work. :wink:

So, here it is. My submission for pcompile 0.1.5.

That being said, I'd suggest the final actual release version be 0.2.0 -- as it is this is in .tar.gz format because there may be further changes you like techno, or I might think of some stupid thing later on.

Anyhow, hope you like it.

Have a play, it all works, at least as far as I could test. :)

Things remaining: src2all is still there, though obsolete.
dump2pet probably needs changes as you'd said.

setting up the pet.specs may be needed but that may already be done by dir2pet, and may want to change that in dump2pet... but that's yours.
Attachments
pcompile-0.1.5.tar.gz
pcompile, new version and new data. Enjoy!
(9.69 KiB) Downloaded 501 times

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

#68 Post by technosaurus »

You have made a lot of progress on this since I last looked. I am working on adding the CFLAGS, CXXFLAGS and LDFLAGS that can just be plugged in to your work. I am attaching a gzip of the window file.

For 1.0 ... we could add some more common options, move to /usr/local (vs shared) and add some dialog boxes (just action buttons) to explain when to use which flags (basically from pet packaging 101 and some stuff I haven't added yet)

For 2.0 ... support for cmake and python...possibly run ldd on all of the bin, sbin and lib directories and filter them through sort and uniq to help determine dependencies
Attachments
window.gz
(1.17 KiB) Downloaded 514 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

#69 Post by Gedrean »

Only problem with /usr/local is that on Puppy default 4.21 (and I think 4.3) /usr/local is NOT in the LD lib search path by default... and that causes anything put in libs there to fail out.

It's been a bug for some time which I've mentioned on other threads, but nobody seems to notice, or the common response is "So add it in yours"...

Anyhow, I already put those C/CXX/LD Flags into the code as you mentioned earlier -- or are you meaning to put them into the window function as well?

Name any and all common options and we can stick them in just fine.

Dialog boxes to explain when to use each flag -- perhaps we use Tooltips? :)

Cmake and Python: You're a madman, sir, you go too far!! ;)

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

#70 Post by technosaurus »

Sorry should have clarified,... just the pcompile directory
Attachments
FLAGS.png
(73.59 KiB) Downloaded 686 times
Last edited by technosaurus on Fri 16 Oct 2009, 03:12, edited 1 time in total.
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

#71 Post by Gedrean »

Unless you mean moving pcompile into /usr/local -- that'd be fine. D'oh. ;)

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

#72 Post by Gedrean »

Alright I went over the window file.

While I like what you're thinking, it will require an additional (one or two or three) extraction loops to determine the flags in the pcomp_script -- and I understand now what you mean.

Move the /bin into /usr/local/bin and move the share/pcompile into /usr/local/pcompile -- would that be about right?

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

#73 Post by technosaurus »

no need to move the stuff in /usr/bin just the stuff in /usr/share

Its not necessary - it could be anywhere - its just where the majority of the puppy projects are and thus where people would expect to find 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

#74 Post by Gedrean »

That's fine. I think I can just make up another few loops for the other flags...

As it is, I'm going to look into renaming a bunch of the flag tricks so they're more descriptive.

I think %'s are gonna be included to make sure there aren't any false positives.

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

#75 Post by Gedrean »

BTW, is it really bad to have the pcompile wrapper script reference the pcomp_script in a relative link rather than absolute? (in otherwords, ../local instead of /usr/local?)

Anyhow it'll be that way in debug until this gets fixed up :)

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

#76 Post by Gedrean »

Alright what's the format for LDFLAGS?

Your picture shows -Wl= but here's what I have so far in the original code:
LDFLAGS=" -Wl,-O4,-Os,-relax,--sort-common,--no-keep-memory,-s "

Anyhow I see your layout there... it's gonna be fun figuring this out.

I already had to fix a few "things" in my own -- found some more glitches!

Huzzah.

EDIT:
Also can you repost your window file as your png screenshot you threw up there has things the copy I grabbed apparently does not.

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

TRAIN OF THOUGHT ON DYNAMIC VARIABLES

#77 Post by Gedrean »

My previous post question remains to be answered, as well as the request for reposting the new version you made of the window file ...

This post is a train-of-thought on how to format options, in cboxes and rbuttons and other formats, to allow dynamic adding of compiler options and other functions to the ./configure or other commands used in the pcompile script called pcomp_script - located in /usr/local/pcompile/ - to allow extension and expansion of functionality while reducing changes in core code.

Previously a fixed "indicator" string of "CB_" was affixed before certain items with a true/false value, namely radio buttons and checkboxes. Inside the full names of these items, a % was substituted for an =.
If the value was true, the CB_ was stripped from the name, any % converted to =, and the resulting name appended to a ./configure argument... meaning any argument could be added in by adding a new checkbox to the window code.

With the advent of changing compiler (CXXFLAGS, LDFLAGS, etc) flags, it is apparent that this system is no longer sufficient for our needs. These other systems follow a whole new format, and require added code to interpret and build, so the existing system is not enough.

Expanding upon that system would just make the interpretation code for the CB_ much more convoluted.

Since on a relatively recent (1.6 GHz single-core 32-bit 2 GB RAM) machine the runtime for the interpretation code is completely negligible, adding additional convolution to those codes would not add CPU time of a noticeable amount.

While that is definitely not representative of the CPU power or RAM of the common Puppy system, even a system running around 700 MHz with 512 MB of RAM should not experience much more than a couple extra seconds of script time with additional code.

In addition, memory usage is minimal.

Really, since our target audience is compiling packages for PET'ing, and probably aware that compiles take forever anyhow, 2-3 seconds won't matter.

However, good coding practice dictates we DO NOT over-convolute the code.
While trying to restrict ourselves to bash-internals is good, making the code as compact as possible so as to make it unreadable, and thus unchangeable later for improvements, is completely bad.

Just changing our format for a new option is also bad, because we have more and more risk of a "false positive" -- that is, something where an entry or a name incorrectly triggers a result, thus breaking functionality.

We require then a format that is sufficiently obscure that false positives are as unlikely as possible, but not so obscure that it is a pain to type out for every entry.

We also want a format with a character that, in a bash command string, cannot be included, because we then don't have our "custom options" field interfering with this either.

To mind, ampersand (&) works as it is the "Job in Background" character.
Pipe (|) works as well, as it is the pipe function in bash.
Percent (%) has worked so far that we know of, but not sure if % is a character that bash would break the command with.

& and | seem to be our likely results for what we want then.

A good overall format should contain multiple "sections", with each having a defined purpose, such that we can use these sections to determine a "dynamic variable" and determine what purpose it serves and how it should be passed.

First, we need a section to indicate it is a dynamic variable. A two-character string, for example "DV" for "Dynamic Variable", could work sufficiently for this.
Previously we had been using "CB" for "CheckBox" but that has become rather broken.
An alternate could be "PC" for "PCompile".

Second, a separator. I think the | character would work good for the separators, and is easy to pull out with our expansion functions.

Third, we need a section to indicate what the function of this particular DV is. Another two- or three-character string would be sufficient for this purpose, much more and the naming convention is too complicated.
This two or three character string should probably be an acronym or abbreviation of its function.
For example, Configure Option could be "CO", and LDFLAG could be "LDF".
These are just examples, and not recommendations.

Fourth, another separator. This separates these "indicators" from the actual name.

Finally, the name. Within the name, any = sign should be replaced by an &. The reason for this is that when passed back by gtkdialog, these options will be followed with ="true" or ="false", thus any = in the name would be harder to parse out. In comparison, once the value is determined to be "true", the & can be converted to an = and the whole name passed as an argument in whatever format is needed.

Since | and & would not be used in arguments to ./configure or any other bash commands, these two characters should suffice for these needs.

------------------------------------------------------------------

RECOMMENDATIONS FOR NAMING OF DYNAMIC OPTIONS:
Use | for separator and & for substitution character.
Use 3 total sections, separated by | separator.
Section 1 - Two-Char Indicator of Dynamic Variable.
Section 2 - 2/3-Char Indicator of DV Function.
Section 3 - Variable/Argument/Option Name.

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

#78 Post by technosaurus »

Very good point. I was forgetting the target audience... better to have some predefined selections that are known to work well and a user defined box for intermediate to advanced users... I have a lot of these predefined already - I can post when I get home tonight. The checkboxes were not well thought out - I don't know what I was thinking with that, but I came to the same conclusion when I started writing the bash for them.

also some programs keep their own FLAGS in the Makefile that override what you specify. Adding this line after ./configure will fix that:

Code: Select all

find . -iname \*akefile -execdir sed -i "s/-O[0-3]/ $PCOMPILE_CFLAGS /g" {} ';' -print
find . -iname \*.mk -execdir sed -i "s/-O[0-3]/ $PCOMPILE_CFLAGS /g" {} ';' -print
To remove debugging support (NOT default because it will break some programs for whatever reason):

Code: Select all

find . -iname \*akefile -execdir sed -i "s/ -g / /g" {} ';' -print
find . -iname \*.mk -execdir sed -i "s/ -g / /g" {} ';' -print
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

#79 Post by Gedrean »

The checkboxes were not well thought out - I don't know what I was thinking with that, but I came to the same conclusion when I started writing the bash for them.
No it's honestly a great idea, it just requires making this a little more standardized and less... simplistic.

To add a new category, we'd just need to add another loop with the right identifiers, and the right compilations, and use that in some command as a var instead of a fixed string.

The flags are still a good idea, we just want to properly format it out.

Also, we want to make sure that the top line in the window for that particular tab indicates these are advanced options, and should be left default if the user is unsure what they do.
Also add in rbuttons for mtune as well as march :)
also some programs keep their own FLAGS in the Makefile that override what you specify. Adding this line after ./configure will fix that
A specific (non-dynamic) checkbox in the app to check to request "override makefile flags" would be good for that concept.
To remove debugging support
Also, the removal of debugging support isn't REALLY necessary. A lot of changes I did so that program-breaking wouldn't occur, like the moving to a sub-dir instead of the main dir (when I was compiling some lib it was like "Not in the main dir, *****!")

Tell ya what, lay out the checkboxes the way you want, in the name just call them CB_<whatevername> for each option, make sure the frame indicates where they should go... and post here the format used for each section/flags/whatever --
(( meaning the format used in bash command line to make those flags active, so like cxxflags="blahblah" -- make sure it's clear how it's supposed to go with multiple options )).

I'll write up the code tonight or tomorrow. It's not at ALL hard to write up anymore. I've gotten the coding bug back and it's just a matter of figuring out how to work it.

BTW, are there any other characters we could do besides pipe and ampersand? Not saying I don't like those but I think & is only bad if it's at the end of a line - I'm not sure if filenames and stuff can have an & in it, so is there any other "command-breaking" characters?

If there aren't and those work fine I'll just use those.
It's no big deal, I just wanna make sure what I can and cannot do with this.

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

#80 Post by technosaurus »

You seem to be working wonders with my simple code hacks and turning into an actual piece of software. Here is an updated window file, feel free to name the variables whatever you like.

everything in CFLAGS goes into

CFLAGS=" $VAR1 $VAR2....-O[s,2,3] -march=i[3,4,5,6]86 -mtune=i686" \
CXXFLAGS=$CFLAGS \
####where VAR1... takes the format

Code: Select all

 -fsee 
<--note spaces before and after
LDFLAGS= -Wl,-O4$VARX$VARY$VARZ \
####where VARZ... takes the format

Code: Select all

,--as-needed
as far as % and & ... \ works for some things (\n for new line) depends on what you use to parse it. To be honest I can't really write a line of code myself but I have a good memory for where to find code that does what I want it to do so I can cut, paste and hack until it works.
Attachments
window.gz
(1.41 KiB) Downloaded 374 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].

Post Reply