Could You please improve project management panels

[Babak M.]

Hello babakm,
Welcome to the forum.

It sounds you already have the concept how the project manager should be. You can submit a feature request, provide all your ideas, including some drafts and pictures. Hopefully some volunteers will be interested and start working on it. If you need it in a hurry, you can consider sponsoring the development or making a bounty:

https://foundation.freepascal.org/
https://forum.lazarus.freepascal.org/index.php/board,41.0.html

Hello Handoko
Thank you for your suggestion.

[Bogen85]

Well, the OT hasn't given any feedback....

Does the abbreviation OT stand for "off topic"?

I believe he meant original poster.

In the context of what Martin_fr said, I'm also sure OP (Original Poster) is what was meant.

[Babak M.]

Well, the OT hasn't given any feedback....

Does the abbreviation OT stand for "off topic"?

I believe he meant original poster.

As you might have understood, I am not very familiar with forums. Also, English is not my first language. I apologize for the late feedback.

[Handoko]

Your English is good. Your suggestion sounds good too, but because I don't develop large projects, I am happy with what Lazarus' project manager can offer currently. Please tell us more about the suggestions, perhaps some screenshots. Good things should be discussed and considered.

[Babak M.]

That is kind of you. I will try to document the project management features in Visual Studio.

[Martin_fr]

In Visual Studio, you can't address a single unit or class outside of a project; you need to create separate DLLs for shared classes.

In C#, there is the concept of namespaces, and you can't have two identifiers, such as variables or classes, with identical names. I tested Lazarus, and it seems that if there are two similar unit names in a primary project and an external package, Lazarus assumes the unit in the primary project.

Well, ok. In Lazarus it is common practice to split larger code bases into packages. And the IDE then deals with that.
But it is not mandatory to use packages for your own code.

In C (and any language) there must at least be a concept how the "global" files are found. E.g. you don't write your own definitions for Windows API, they exist outside your project. So inclusion of files outside the project exists. The question simple is, if it is common for your own code to exist outside if it is common to more than one project.

In Pascal, every unit must have its own distinct name too (namespaces will eventually come...). But my example was different: 2 Units with the same name, but each project only uses one of them.
So in each project, all unit have distinct names.
But in the project group they don't, and they don't need to.

In Visual Studio, you can run more than one project at the same time. In other words, in the solution options, you can configure multiple startup projects. Also, there are options to rebuild and clean either a single project or all projects together.

Ok, so that makes sense.

I can see  2 ways for that.

1) Having some "build and run" settings in the project group.

Personally I don't like that. It makes thinks complicated for the user, as the same functionality appears in project and group. And also, its only for a subset of project groups. As many project groups may be a loose collection of projects.

2) Having settings in each project.
Where a project could (per buildmode) specify (a list of) other projects that get build and/or run in a specific order.

So then you would have one "main" project from which you manage everything.

The other projects would be to store settings for each of them.

Downside: It may then be more work to change settings for all projects. As they need to be changed in each of the projects. (if it is more than picking a different buildmode)

----
But, then it occurs to me, that some of stuff for having multiple "apps" may already be possible from within a single project.
The only thing missing is, that you can set a "main source file" per buildmode.

Currently a project has a single *.lpr file (containing the program or library). The startpoint for the compilation.
If You could change that in the project settings, then you already might the ability to have the same settings for different "apps".
So you would only have one per buildmode, and could only run the one at each time.

It would require careful consideration, but could be interesting.

Does the abbreviation OT stand for "off topic"?

Yes, but it is a type. I meant "O.P." => Original Poster => you.
Sorry about the confusion caused.

I didn't want someone to reimplement Visual Studio's Solution Explorer in Lazarus.

I think there are many dialog forms for managing files in Lazarus that could be removed and integrated into a single panel. I am not the Lazarus project manager; I only sent my request as a user. Although my name is on the Lazarus contributor list, which makes me proud.

I understand, VS is an example. But as I said, not useful for me, because if I don't know how the example does it, I can't share ideas on it.
Hence I tried to get you describe details. Also more important than describing the functionality, is to explain the workflow you try to achieve.


About "just integrate 2 into 1": Personally I like to have the project and project group separate.  As I said, it allows me to open a project that is not in the group, then afterwards quickly return the group by opening a project from the group panel.
For me that is something that must be kept.
=> If both panels become one, that would lead to very awkward behaviour. Then the group would need to be able to show me a project that isn't part of that group.

Also, I might miss something in your request. Because given we have anchordocking, you can just dock those 2 together. And yet, if you prefer have all other windows undocked.
Ok in that case the active project would be show at the bottom of the combined window, rather than maybe inlined in the tree. But otherwise....?

So is that really it, or is combining them more about functionality that currently isn't there. I.e. make it work different?

Maybe like that projects in the same group are less separated, and start sharing certain details? But then it would need to be known what those changes are.
And also how to provide for people who want to group projects, but have those projects keep there independence as they do now.



Project group currently offers to "run" any of the projects in it.
But...
- that is hidden in the context menu.
- It opens the project, changing what you have open in the editors
- only runs one at a time (that is a limit on a different scale though, but still)

So, if we could in each project introduce dependencies what other project need to be compiled and run (and in which build mode, so you don't need to change the buildmode on the other project / you only need to go the the other project to initially create that build mode).

If we could allow actions in the group on each project without the need to open the project in the editor (so your session, your open files stay as they are).

Would that be a step towards what you would like?

Mind that both of those are rather very complex changes.
Currently the concept of ONE SINGLE PROJECT is extremely deeply rooted throughout the entire IDE. Changing that is not easy. Though eventually it needs to be change, not just because of the things discussed here...

[Babak M.]

Well, ok. In Lazarus it is common practice to split larger code bases into packages. And the IDE then deals with that.
But it is not mandatory to use packages for your own code.

Dividing a project into packages promotes code reuse and simplifies the management of large projects, but it has some disadvantages. For example, statically linking can increase the size of the executable file, and any updates to the packages require recompiling the entire project to incorporate the changes.

In C (and any language) there must at least be a concept how the "global" files are found. E.g. you don't write your own definitions for Windows API, they exist outside your project. So inclusion of files outside the project exists. The question simple is, if it is common for your own code to exist outside if it is common to more than one project.

In C#, you don't have to write separate .inc files for your libraries, as all backend service definitions are included in the DLL binary.
If you are going to undertake a large project, you should choose a scalable architecture such as a multitier architecture. In N-tier applications, it is common to share a DLL layer among others, although each layer shouldn't engage with the details of other layers. As a result, having a solution for declaring an interface for DLLs is mandatory.

https://en.wikipedia.org/wiki/Multitier_architecture

In Pascal, every unit must have its own distinct name too (namespaces will eventually come...). But my example was different: 2 Units with the same name, but each project only uses one of them.
So in each project, all unit have distinct names.
But in the project group they don't, and they don't need to.

As I know, parsing and analyzing code is the main difference between a simple editor and an IDE. All IDEs continuously parse your code to understand its structure and syntax. This involves breaking down the code into tokens and building an abstract syntax tree (AST) to represent the code's structure.

All useful and important features, such as syntax highlighting, code completion, code navigation, and refactoring tools, need a powerful parser at the heart of an IDE. I think the Lazarus parser can find an identifier's definition even if there are two similar definitions in different projects..

[Babak M.]

Ok, so that makes sense.

I can see  2 ways for that.

1) Having some "build and run" settings in the project group.

Personally I don't like that. It makes thinks complicated for the user, as the same functionality appears in project and group. And also, its only for a subset of project groups. As many project groups may be a loose collection of projects.

2) Having settings in each project.
Where a project could (per buildmode) specify (a list of) other projects that get build and/or run in a specific order.

So then you would have one "main" project from which you manage everything.

The other projects would be to store settings for each of them.

Downside: It may then be more work to change settings for all projects. As they need to be changed in each of the projects. (if it is more than picking a different buildmode)

I think it is not necessary to move project build settings into project group settings. Adding some startup priority options for projects in project group options is sufficient.

----
But, then it occurs to me, that some of stuff for having multiple "apps" may already be possible from within a single project.
The only thing missing is, that you can set a "main source file" per buildmode.

It is not common to change the entry point of a project in the project settings. Every project must have a constant entry point

I understand, VS is an example. But as I said, not useful for me, because if I don't know how the example does it, I can't share ideas on it.
Hence I tried to get you describe details. Also more important than describing the functionality, is to explain the workflow you try to achieve.

Suppose that your team must undertake a large project, such as an ERP solution software. In this situation, divide and conquer is a key strategy for your development progress. You have to create reusable artifacts such as DLLs or packages to simplify teamwork.

Reusability and testability in large projects are crucial. You cannot test all components of a huge executable by hand, so you need an automation tool. Your software components interact with each other, and circular references must be prevented.

A common workflow is dividing the domain into sub-domains and sub-projects. After that, an architecture is chosen. Architectures such as Onion or traditional Client/Server determine the boundaries between project components.

About "just integrate 2 into 1": Personally I like to have the project and project group separate.  As I said, it allows me to open a project that is not in the group, then afterwards quickly return the group by opening a project from the group panel.
For me that is something that must be kept.
=> If both panels become one, that would lead to very awkward behaviour. Then the group would need to be able to show me a project that isn't part of that group.

I usually open two IDEs for different projects simultaneously

[Martin_fr]

I think it is not necessary to move project build settings into project group settings. Adding some startup priority options for projects in project group options is sufficient.

Good. Glad to hear.

It is not common to change the entry point of a project in the project settings. Every project must have a constant entry point

Ok, so one point to look at is how to 1) compile 2) run several projects with one command?


Did you see my earlier idea?
To add that to each project (and within each project, even per buildmode).

So then like you can have a Release and Debug build mode, you could have a "Run with <Other Project>" or "Run with <mock project>".

And there you would have a list of tasks for each compile or each run. Maybe an extension to the "compiler commands".
The list would contain entries with
- reference to another project
- checkbox to compile that other project with specified buildmode
- checkbox to run that other project
- maybe some wait time after running it, before doing the next.

[Babak M.]

If I understand your ideas correctly, I must create a single project and get multiple outputs by defining various compiler options. I think it is a weird solution for multiple projects and it breaks the K.I.S.S. principle. You should consider common IDE behaviors when dealing with this problem. You probably have new users from other IDEs who say that Lazarus is an alien IDE.

I will try to explain common tasks in my desired project manager. I hope I can clarify my expectations.

In fact, the project manager is a tree of projects. It has a root with a name and a context menu including these items:
•  Rename option
•  Add New Project
•  Add Existing Project
•  Build (Build all projects)
•  Clean (All projects)
•  Rebuild (All projects)
•  Options (This item enables the user to choose a single or multiple projects as startup and their running priorities)

Under the root of the project manager, there are projects, and they also have a dedicated context menu including the following items:
•  Rename and Delete options
•  Add New Item (Including all Free Pascal files such as unit, form, frame, resources, etc.)
•  Add Existing Item
•  Add Folder for organizing files
•  Build (Only this project)
•  Clean (Only this project)
•  Rebuild (Only this project)
•  Options (Including CPU architecture, build mode, output path, other compiler options, starting wait time, required packages, and adding an existing project reference. Project references help the compiler determine which project must be built first)

You can filter tree items. There are also common file commands such as copy, paste, delete, and rename. There is more than one project, so the compiler needs to compile them one by one. Project references specify build priority. After the compilation phase, the compiler runs projects based on project root options, considering the wait time in project options.

[Martin_fr]

If I understand your ideas correctly, I must create a single project and get multiple outputs by defining various compiler options. I think it is a weird solution for multiple projects and it breaks the K.I.S.S. principle. You should consider common IDE behaviors when dealing with this problem. You probably have new users from other IDEs who say that Lazarus is an alien IDE.

No, you will still have several projects (one for each produced binary).

But the problem that if you want to run your client, you may need 2 dll rebuild, and the server build and started, that would be solved by the build lists.

E.g. A build list could look like
- Before running the project do:
-- build MyLibFoo
-- build MyLibBar
-- build and run MyServer (and wait 1.5 seconds for it to start)

The server will just be started, it wont be debugged (as currently only one project can be in the debugger, and that will be the client)

MyLibFoo is a project of its own. But you can refer it in the build list, so that it is easy to trigger.

I will try to explain common tasks in my desired project manager. I hope I can clarify my expectations.

In fact, the project manager is a tree of projects. It has a root with a name and a context menu including these items:
•  Rename option
•  Add New Project
•  Add Existing Project
•  Build (Build all projects)
•  Clean (All projects)
•  Rebuild (All projects)
•  Options (This item enables the user to choose a single or multiple projects as startup and their running priorities)

Under the root of the project manager, there are projects, and they also have a dedicated context menu including the following items:
•  Rename and Delete options
•  Add New Item (Including all Free Pascal files such as unit, form, frame, resources, etc.)
•  Add Existing Item
•  Add Folder for organizing files
•  Build (Only this project)
•  Clean (Only this project)
•  Rebuild (Only this project)
•  Options (Including CPU architecture, build mode, output path, other compiler options, starting wait time, required packages, and adding an existing project reference. Project references help the compiler determine which project must be built first)

You can filter tree items. There are also common file commands such as copy, paste, delete, and rename. There is more than one project, so the compiler needs to compile them one by one. Project references specify build priority. After the compilation phase, the compiler runs projects based on project root options, considering the wait time in project options.

The root is also a project? Or the root is the "project group"?
Because the "project manager" sounds to me exactly what the project group is meant to do. Except that the project group has only a subset of the features.
But some of those options already exist in the project group. (build/run, buildmode, even project properties)

And yes, the project group is a separate window. And merging it or not is a matter of taste, and some will want it merged, others will not. So that isn't easy to solve.
But IMHO the more important part is functionality.


The problem is that many of the feature force the project to be opened in the editor (merging the windows will not change that / It should be improved, but that is independent of the 2 window decision).
Try what happens when (in the project groups) you select "properties" from the context menu of a project (that is not currently open).

Once that is fixed, adding more of the items you mentioned, will likely by easy.
Fixing that is probably a bigger task.

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

The above points are of course only a subset of the differences to workspaces.

But they are about those issues that I thing I identified from this post/thread. (If indeed I actually understood them, if not ...)

[Martin_fr]

Adding some startup priority options for projects in project group options is sufficient.

I overlooked that before. What do you mean by "startup priority"?

Does that refer to compiling and/or running apps from the project-group? Or does startup stand for something else?

The project group only start (runs) at max one project at a time, and that is the selected project if and when you select "run" from the context menu. So for that I would not expect a priority to be needed?

Or am I missing a part, and this requests that the project group can automatically run several projects (on some trigger)?

Project references specify build priority. After the compilation phase, the compiler runs projects based on project root options, considering the wait time in project options.

The order of building should not matter. Well packages must be done in the right order => but the IDE can figure that order out by itself.

For projects  the compiler should find for each source if the ppu is up to date or needs compiling.  (there are some issues in some fpc versions, but I am not sure if order would help against those bugs).

So whichever project you build first, will compile all files it needs. The next will compile the files that haven't yet been build. That works in any order in which the projects could be build.
Of course if your build has external scripts that create artifacts, and they are then used by later builds, then that differs.

But then that order could be different depending on which project you currently have open.
A testcase may need other builds than the real app.
So those build orders must be configured within each project (that is what I suggested the "build list" would do).

[Babak M.]

The root is also a project? Or the root is the "project group"?

The root is not a project; it is a container for other projects. In Visual Studio, the root is called a solution. The solution actually is a container for projects and has a few options for choosing run priority.

When you click the run button or press F5, all projects are built by VS automatically. Because of project dependencies, there must be a build order that VS considers, but you have not set it by yourself in compile options. If there is a circular reference, VS is not able to compile the projects, and you encounter a "there is a circular reference" compiler error.

Or am I missing a part, and this requests that the project group can automatically run several projects (on some trigger)?

Yes. After the compilation phase, if you need to run more than one project, for example, in a client/server architecture, there are run order options in the solution properties. In other words, you can set which project must run and which one starts first. Also, you can debug all projects Simultaneously.

But then that order could be different depending on which project you currently have open.

In Visual Studio, when you open a solution, all related projects are opened at the same time. You don't have to select a project as an active project; you can edit all project files freely.

I have worked with Android Studio and Eclipse as well. This is the common mechanism for managing multiple projects. I recommend you install a trial version of VS and try it yourself.

[Martin_fr]

The root is also a project? Or the root is the "project group"?

The root is not a project; it is a container for other projects. In Visual Studio, the root is called a solution. The solution actually is a container for projects and has a few options for choosing run priority.

Ok, now I get slightly confused...

I had a similar conversation with someone else, and they said "In VS you have Solutions in a Workspace" => making it sound like solutions are the project.

But according to https://learn.microsoft.com/en-us/visualstudio/ide/solutions-and-projects-in-visual-studio?view=vs-2022
- Solutions:
 

It's simply a container for one or more related projects, along with build information

  Solutions are project groups.
- And projects are also called project.

The difference seems to be that VS has all build/run related stuff in the project group. Lazarus merely offers to trigger the build/run from the group, but has the settings (and tools) in the Project.

However, there also was the mention of Workspaces, and they seem to exist https://learn.microsoft.com/en-us/visualstudio/extensibility/workspaces?view=vs-2022
But there is no info how they relate to solution or project.

Anyway that does not really much matter, except for: If/When we use them in this conversation we need to set out a definition what we mean by them.

So for all purpose, I assume that both "Solution" and "Workspace" shall mean project group. That is, they are containers for projects. All other functionality follows from that definition.


Then in terms of this discussion (this forum thread here):

Our main topic are
- how building multiple projects works?
- Combining the two features (visual or functional)

If there are other issues then please remind me.

About "Combining" .
If that is just putting both windows into a single window => but keep the exact same functionality, then my opinion is that should be left to docking. There are users who like to have the separate Windows (e.g.: me).

Functional: That may be discussed.
The project group already provides access to many of the project tools and options. If there are one or two others to be added => probably fine. -- Though, depending on what it is, it may need only make sense, if the IDE can do that without loading the sources of the project into the editors. (As I said, try to access the properties of a project in the group / A project that is NOT the current open project).

Once that is possible, we can see which extra buttons or menu entries to add to project groups. (Well we can before if there are features that don't need to open the project). You already gave a list (rename/ move ...). That is a starting point.

When you click the run button or press F5, all projects are built by VS automatically. Because of project dependencies, there must be a build order that VS considers, but you have not set it by yourself in compile options. If there is a circular reference, VS is not able to compile the projects, and you encounter a "there is a circular reference" compiler error.

Or am I missing a part, and this requests that the project group can automatically run several projects (on some trigger)?

Yes. After the compilation phase, if you need to run more than one project, for example, in a client/server architecture, there are run order options in the solution properties. In other words, you can set which project must run and which one starts first. Also, you can debug all projects Simultaneously.

Ok, unless I missed it (in which case I am sorry) I had no feedback to my latest "build list" comment.

IMHO "building all projects" is a subset of "building a group of specified projects".

And, IMHO "building all" is rarely needed during development. Since we talk about using proper design, I assume testcases, and mock entities are part of the development process. So I would expect that in a project that size, over 90% of all builds are some testcase, wich will only include one or two "live" projects, and "mock" projects for the rest.

So you do need a place to define "list of projects" that need to be build depending on what you are changing and testing. => That is the aim of the "build lists" idea.

In fact, you may get conflicts if you build mock and live entities at the same time, if they both produce the same binary in the same location. So you definitely need to be able to choose.

But then that order could be different depending on which project you currently have open.

In Visual Studio, when you open a solution, all related projects are opened at the same time. You don't have to select a project as an active project; you can edit all project files freely.

I have worked with Android Studio and Eclipse as well. This is a general mechanism for managing multiple projects. I recommend you install a trial version of VS and try it yourself.

Ok, in Lazarus that probably wont happen. There will always be a project open.
Otherwise we end up having to completely different project management concepts within one IDE => that is a sure concept for chaos.

However, what we may need is a way to change project, without changing the files that are open in the editors. (aka session).
And if we do have that, then changing projects should not be a big issue.

Just to say you can have several projects sharing the same folders and the same units in those folders => that already works....
IMHO it is a mess, and even some VS users told me that they wish there VS work was better organized.... But again, if you do not want structure in your projects => it is possible (already today).
(Sorry that statement is a bit biased by personal emotion...)


However, once you have
- projects that can share a session / can be switched without changing the open editors
- can live in the same folder, sharing the same sources

=> then having the "build lists" on those projects should actually an advantage towards VS having build staff on the group.
You can then without side effects switch projects to indicate if you want to run a testcase, or the real thing, or .....
And then build/run will build exactly that, and with no extra overhead, no time wasted on building something that you do not need to be build.

One point that is not in the above is "sharing build options" across projects.

- How to change all projects between release and test building.
- How to add a define to the test or release settings of all projects.

That still needs to be addressed.

It is separate from "what gets build". This will be "how it will be build".

There may need to be some control of this "how" in the group.
However, at the same time projects need to be able to have control themself. Because some people (like me) currently have groups in which each project needs to have its own settings.
IMHO it should probably end up with each project having an option if it follows the group or not.



Now this are my thoughts....

You may have a different opinion. And if you can show me that it has serious advantages, then please do.

To me, the main point is to provide the features  that you have in VS (or in other words "allow to do the same things with similar effort").
But not necessarily the same user interface. Not even necessarily the same concepts. (There may be better concepts after all / and we need to integrate our existing concepts without loss or duplication).

 

[Martin_fr]

Post 11 https://forum.lazarus.freepascal.org/index.php/topic,69412.msg539706.html#msg539706

In the 2nd image: How many such settings for "startup project" can you have in a solution?
E.g. could you create something like "build modes" in Lazarus, and for each such "build mode" have a different setting for "startup project"?

My "build list" idea is meant to provide those settings.
That is:
- Each entry in a "build list" would be like a "startup project" config.
- You can have many such entries.

One difference though:
- You will have a "primary project" for the startup.
- you chose that "primary project" by opening that project from the project group (much like current Lazarus does)
- Within that project you then chose an entry from the build list (if you have multiple entries, otherwise there is no choice)

And that entry that you choose from the build list, will then specify what else to build and in which order.

It is one step more, but only if you have several entries in a list for the chosen project. And then you have chosen so, which means you should have seen a benefit in it.

Also, you may be able to chose the entry like a build-mode directly in the group-window. => Then it is one step.
The difference then is that your "startup project" configs can be grouped by primary project. But you can also put them all on one and the same project.....