<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi<br>
<br>
I wanted to make sure you step back a bit and take a very broad<br>
view of this project. It is fun to jump in and code but this
project<br>
really requires more than that. We have had this idea for years<br>
but not pushed it because of this. With my recent work on the<br>
configuration chapter, a lot of heavy lifting that we couldn't <br>
expect a student to do has been done. Without deep knowledge<br>
of RTEMS, no one could present the configuration parameters<br>
in a more uniform manner. [1]<br>
<br>
Here is what this project needs as basic requirements:<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
(1) describing the parameters<br>
(2) saving user selections<br>
(3) generating appconfig.c (arbitrary name)<br>
(4) UI implementation(s)<br>
<br>
(1) needs to be shareable in a computer manner between<br>
the users guide and the Configuration Tool.<br>
<br>
All user dialogs need to be generated based on descriptions<br>
of the parameters. There can be no hard-coding of menu <br>
options. If we add or delete a parameter, this should just<br>
fall out naturally from the descriptions.<br>
<br>
There needs to be a file format to save user selections.<br>
This file format needs to be the same independent of UI.<br>
The user should be able to generate a configuration,<br>
come back later, load it, edit it, and regenerate C code.<br>
<br>
The UI must be portable between all major platforms including<br>
Linux, *BSD, MacOS, and Windows.<br>
<br>
(1)-(3) could be completely using text editors and defined file<br>
formats and transformations. Any tools could be command line.<br>
<br>
And any transformation between Users Guide and UI configuration<br>
parameter must likely be command line.<br>
<br>
The UI (4) could be a command line tools to transform (2)<br>
which is in ASCII into a C file to be compiled. But the UI<br>
could also be a TUI (Text User Interface) using ncurses<br>
or true GUI using Python. <br>
<br>
Ultimately the definition of (1)-(3) make it possible to <br>
implement multiple UIs. But we need a simple portable<br>
one first that assumes little. I assume that means a TUI<br>
and next a GUI.<br>
<br>
If you are clever, you can do all of this with some transformation<br>
and magic of reading files and generating various dialogs in TUI<br>
and GUI form.<br>
<br>
Chris is the resident Python wizard and offered to help<br>
define classes to do the transformations. Python is a very <br>
portable language and toolkit which should be easy to <br>
dynamically generate UIs in -- both TUI and GUI. Using one<br>
implementation language would allow you to share the <br>
"controller" portion of the program but implement <br>
different "views". [2]<br>
<br>
<br>
I hope this helps you get a broader view of this project.<br>
And I hope this has given you requirements.<br>
<br>
--joel<br>
<br>
[1] I don't mean this to brag or denigrate. I invested a
significant<br>
amount of personal time in rewriting this chapter. And I have <br>
sections that I need help to improve still. I did this both to<br>
improve the documentation and make a big step to providing the<br>
definition of the configuration parameters in a computer<br>
parseable form from which dialogs could be generated. I hope<br>
I succeeded.<br>
<br>
[2] I guess I am making an executive decision. Implement this<br>
in Python. Focus on (1)-(3) first with the focus on being able to<br>
read this and generate the bulk of the UI based on the various<br>
types of configuration parameters.<br>
<br>
On 04/07/2013 06:09 PM, Chris Johns wrote:<br>
</div>
<blockquote cite="mid:5161FC8E.8070005@rtems.org" type="cite">
<pre wrap="">Shubham Somani wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Crosstool-ng would indeed work very well with linux systems.
</pre>
</blockquote>
<pre wrap="">
I do not use Linux so where does that leave me. Unless you intend to
support native Windows, MacOS, FreeBSD, ie what is not Linux as well,
then this tool will be of little value to me or those who do not use
Linux as a development environment.
</pre>
<blockquote type="cite">
<pre wrap="">But I did some research and found out some drawbacks of running
crosstool-ng on cygwin and mac as given on their site
<a class="moz-txt-link-freetext" href="http://pastebin.com/NiLxUqdz">http://pastebin.com/NiLxUqdz</a>
</pre>
</blockquote>
<pre wrap="">
This is what I was talking about. You are not picking up an easy to use
package, you are fixing a part of another project. Unless you work in
that project to first fix it there you could potentially create a fork.
Chris
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Joel Sherrill, Ph.D. Director of Research& Development
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35806
Support Available (256) 722-9985</pre>
</body>
</html>