BlackBox Framework Center

This would be my proposal for a MakeList command embedded in DevCompiler.
I still believe it is the most adequate approach.
If you look at the docu, you can see the close relation of MakeList to CompileModuleList.

See the diffs at http://redmine.blackboxframework.org/pr ... c73e8746c7.

- Josef

I believe that this is the design mistake. We should not add some "help" tools into the Compiler module.

1. No the fact that it will be useful at all by many users, but if you add this tool to main module of Dev, you are showing that is is very important stuff, but it is not.
2. Compiler is the essential enter point into the Dev subsystem. Is is the main module, which should be clean.

Josef, you have done a create job. Now an important missing tool is added to the right place.
DevCompiler.MakeList is easy to remember.
- Helmut

AddModule has a problem,the need changed to to ensure the complication order;

IMO,
1,the three Node type can be reduced to one Node type;
2,the Node'name can be an array instead of a pointer;
3,MakeSubsystems is no need,it body can move to MakeList,basically,it's subtool,have the MakeSubsystem is good enough.
4, DevCPT no needed, DevCPM,DevCPS is enough(maybe i'm wrong)
5,add "DevCompiler.CompileThis" is an option

though I have myown subtool,but it is not base on Dev moudles(unfamiliar with it as a sacnner,parser alone,afraid of resource leakage, heavy... ),it is much more complex than yours;
actually,the current framework is not out-of-box,some basic features like: file browser(weak),source browser(Navigator,lacked),beautifier(lacked) etc. need you add them manually if you have,
otherwise it's not as good as notepad++ on editing works;

though,these problem can be solved by a package manager which we have discussed ever,
but Builtining with such necessary tools(functions) will be welcomed by end user,out-of-box product;certainly,the high quality code like this is nessary,as little as possible;

luowy

We have for example Info -> Source, Info -> Interface and so on ...

So I just have the idea of adding to the menu
"Make Compile List" "" "DevCompiler.MakeList" "TextCmds.SelectionGuard"
and select
Obx Text
After I click on the menu Make Compile List, I get the message: no text view found.

Question: Does it make sense to add this facility?
- Helmut

Zinn wrote:Question: Does it make sense to add this facility?

Folks, this is the migration tool. Maybe someone will find it useful. Maybe will not find.
We do not need an menu item for this and we do not need to make an accent that it is very useful feature by adding it in the Compiler module.

Each BlackBox extension usually has an compilation list proposed by the developer.
Developer can control this list easily during the development.

So the new option can be used by developer mainly during migration of unstructured modules without documentation or during some big refactoring work.
This are rare cases when it will be useful.

Since my design argumentation (why it should be in DevCompiler) based on a potential useful extension
towards "CompileSubsystems" is too abstract for some, I have now added this to DevCompiler.
It is a very small extension that builds on the already existing procedures for MakeList.
It should now show to everybody that this functionality really belongs to DevCompiler.

See the diffs at http://redmine.blackboxframework.org/pr ... e7fbadeea5.

Thanks to luowy for pointing out a possible simplification.
It is not yet included but I will look at it shortly.

- Josef

Thanks Josef, now this design has sense. I checked the version
http://blackboxframework.org/unstable/i ... c1.674.zip

I am ready to vote for this.
Just two small fixes in the documentation. The link to the Platform-Specific Issues should be 10pt and CompileSubs need to be in the interface description at the top.

@luowy:

> AddModule has a problem,the
I must think about this. Could you give me an example of a problem?

> 1,the three Node type can be reduced to one Node type;
Right. At least up to the current state it turned out that all lists have the same structure.
If this remains so, they should be unified.

>2,the Node'name can be an array instead of a pointer;
What is the size of the array? Naturally, it would be 256. But this means half a KB for every node and
this would waste a lot of memory. But I think I have a nice compromise by introducing a constructor,
which would give sense if all lists are unified.

3,MakeSubsystems is no need,it body can move to MakeList,basically,it's subtool,have the MakeSubsystem is good enough.
See CompileSubs.

> 4, DevCPT no needed, DevCPM,DevCPS is enough(maybe i'm wrong)
Right.

> 5,add "DevCompiler.CompileThis" is an option
I don't understand the meaning of this

In addition, I have just seen that error handling in CompileSubs does not open the view.

Can someone please test the extensions with non-ascii module/file names?

@Doug: for voting the missing details need to be fixed first.

- Josef

Josef Templ wrote:Could you give me an example of a problem?

I test within myown work copy,found some
found the module list order is not correct; it need some time to give you a clean test demo;

Josef Templ wrote:> 5,add "DevCompiler.CompileThis" is an option
I don't understand the meaning of this

I mean give user a normal compile work way which we often used at "Quick-Start" document.like
^DevCompiler.CompileThis ObxTest1 ObxTest2 ObxTest3 ObxTest4
currentle the output modulelist worked only "selection" mode;not convenient,IMO.