Opening multiple projects with the same name

[Erik Rull]

Hi all,

I work on a multi branch project and work on multiple branches in parallel
- so I have the code checked out for multiple platforms and multiple
branches at the same time (in different directories, of course!).
But I can open only a single project with the same name. The kdev-Project
files are checked into the source control repository so that others can use
it, too and that I can work on any branch after a checkout directly by
opening the project.

At the end - kdevelop4 (IIRC 4.7.3) complains if I want to open a second
checkout of the project - due to the same project name.

How can I open multiple projects of the same name at the same time in the
same kdevelop-instance?

Thanks!

Best regards,

Erik

[René J.V. Bertin]

On Sunday February 11 2018 21:41:06 Erik Rull wrote:

Hi,

Post by Erik Rull
How can I open multiple projects of the same name at the same time in the
same kdevelop-instance?

The short answer is something like "try first wit KDevelop 5.2.1 but I don't think you can". I don't think that is not intentional (probably on the contrary; project settings are stored under a directory with a UUID), so your best bet would be to try with the latest release and then file a ticket on BKO if it doesn't work as you expect.

In my experience KDevelop doesn't use the project name consistently and to the fullest possible extent, and that experience doesn't even involve trying to open multiple projects with exactly the same name. I've posted about this before, on one of these two MLs or as a wishlist ticket on BKO (along with a patch that I think improves certain aspects: https://phabricator.kde.org/D9344).

One issue that you will certainly run into, probably with a vengeance, is that navigation aids like the outline dropdown widget already have trouble taking you to the correct file in which the function you selected resides, if you have multiple files open that contain the same file. Even if you think you use the widget to jump to another function in the same file, you may end up editing the file from another project. I'm 99% certain that others have reported this issue too, and for me it persists in the latest 5.2.1 builds.

HtH (against all odds 8-) )

R.

[René J.V. Bertin]

BTW,

Post by Erik Rull
- so I have the code checked out for multiple platforms and multiple
branches at the same time (in different directories, of course!).

I was going to try for myself, but I need a bit more specific information for that.

By default KDevelop will name projects after the directory from which it loads the [C]make or .pro file, and it will create a pair of .kdev4 files with that same name, giving

foo/foo.kdev4
foo/.kdev4/foo.kdev4

AFAIK the name you enter in the project wizard is stored in the foo/foo.kdev4 file and used only (chiefly?) to disambiguate the entries in open file lists when you have multiple files with the same name open from different projects (as well as in the titlebar).

So what do you mean with "different directories"? Are we talking different names of the final directory on the path (/a/b/c/{d,e,f}) or about paths that differ somewhere but not in the final directory name (/a/b/c/d, /a/b/e/d, /a/f/c/d)?

R.

[Erik Rull]

Hi,

Post by René J.V. Bertin
BTW,
By default KDevelop will name projects after the directory from which it loads the [C]make or .pro file, and it will create a pair of .kdev4 files with that same name, giving
foo/foo.kdev4
foo/.kdev4/foo.kdev4

Yes, these files are existing and are checked into Version Control System.
So they are available on all checkouts / branches at the moment.

Post by René J.V. Bertin
AFAIK the name you enter in the project wizard is stored in the foo/foo.kdev4 file and used only (chiefly?) to disambiguate the entries in open file lists when you have multiple files with the same name open from different projects (as well as in the titlebar).
So what do you mean with "different directories"? Are we talking different names of the final directory on the path (/a/b/c/{d,e,f}) or about paths that differ somewhere but not in the final directory name (/a/b/c/d, /a/b/e/d, /a/f/c/d)?

I have the source code structure e.g.:

foo/x
foo/x/y
foo/x/z

and the kdev-files located as described above.

Now - I check out multiple instances (different branches) into:

/home/erik/a/foo/
/home/erik/b/foo/
/home/erik/c/foo/

I open the project located under /home/erik/a/foo/ and when I try to open
/home/erik/b/foo/ - kdevelop complains.

Going to 5.x is currently a bit tricky, but I'm willing to switch and test
it as soon as there is a LTS version of kubuntu supporting it.

Post by René J.V. Bertin
R.

Best regards,

Erik

[René J.V. Bertin]

Hi,

Post by Erik Rull
I open the project located under /home/erik/a/foo/ and when I try to open
/home/erik/b/foo/ - kdevelop complains.
Going to 5.x is currently a bit tricky, but I'm willing to switch and test
it as soon as there is a LTS version of kubuntu supporting it.

OK, with that I'll try to reproduce this tomorrow in a very recent 5.2.1 build.

You can however try the AppImage version of 5.2.1, available via kdevelop.org . That is a fully standalone build which you should be able to run without installing anything.

R.

[Erik Rull]

Hi,

I took the AppImage - first start killed my X, second start worked. Same behavior with this version.

If you have other ideas how to solve the issue without starting new projects with each branch / checkout, please let me know.

Best regards,

Erik

Post by René J.V. Bertin
Hi,

Post by Erik Rull
I open the project located under /home/erik/a/foo/ and when I try to open
/home/erik/b/foo/ - kdevelop complains.
Going to 5.x is currently a bit tricky, but I'm willing to switch and test
it as soon as there is a LTS version of kubuntu supporting it.

OK, with that I'll try to reproduce this tomorrow in a very recent 5.2.1 build.
You can however try the AppImage version of 5.2.1, available via kdevelop.org . That is a fully standalone build which you should be able to run without installing anything.
R.

[René J.V. Bertin]

Hi,

Post by Erik Rull
If you have other ideas how to solve the issue without starting new projects with each branch / checkout, please let me know.

Would it be acceptable to check out those different branches into directories with distinctive names? No guarantees, but it's possible that this may allow you to open the projects via the "official" .kdev4 file in the toplevel directory, with KDevelop maintaining a dedicated file in the .kdev4 directory.

I've come to the conclusion myself that it is not usually a good idea to put the foo/.kdev4/foo.kdev4 file into VCS. It contains absolute paths and other host+user-specific data along with data you might conceivably want to be able to share (like cmake options, source formatting settings, preprocessor macros etc). Other IDEs typically separate those things and/or store certain information like build and search path directories in relative form (even if at runtime they convert that to absolute paths) - Xcode does for certain, MSVC and QtCreator too I think.

I think it's probably safe to say that KDevelop could see some improvement in its support for true collaborative approaches where you manage more than just the code centrally (and DON'T use KDevelop's defaults for everything ;))

If anyone else is reading this: I've already encountered one or two foo/.kdev4/_custom.kdev4 files; is that what I'm hinting at here and if so, how does one get KDevelop to use them?

Not really up to me to say it but the usual reply here is "patches welcome". (But know that due to KDevelop's modular design a proper implementation of this kind of change is probably going to be quite the overhaul.)

R.