Make target settings are behavior incompatible

[Andras Mantia]

> On 07.01.07 11:20:29, Andras Mantia wrote:
> Both ways are now handled as good as we can, by providing Message Boxes
> upon project opening telling the user that there's no active target and
> when trying to execute the project or active target without one beeing
> existent another msg box comes up that tells you so.
Good.

> :) Not a problem, but I thought you know as you seem to have used
> kdevelop for hacking on quanta where you'd use a custom makefile
> manager/

Well, 3.5 it's automake based, why would I need a custom makefile manager?

> First of all the .kdevelop file is not meant to be put in SVN (check
> kdevelop3.4 and 4, neither of those has a .kdevelop file in SVN anymore
> for the exact reason that the file contains local paths and user
> preferences). It already contains at least 2 local settings that one
> needs to change if he wants to use the .kdevelop file.

I know, and I don't care. I'm almost the only one using that .kdevelop
file, and it was there in the svn since ages. It's true that it doesn't
work for others, but it is a start for them, as they just need to change
the directory settings and it should work like for me.

> And before you ask, the proper "workflow" is to import the project into
> kdevelop after checking it out from svn, instead of opening such a
> source-controlled .kdevelop file.

Again, it is not relevant here. I have a project. Sincerely I do not
remember how I created it as I have since a very long time. Probably I did
how you wrote, by importing the sources. The problem appeared that I
updated Kdevelop, opened my existing .kdevelop project and suddenly things
did not work as before.

> And the reason why you get the home dir in the filedialog is that
> quanta/src/quanta is set as main executable and this is not an absolute
> path. So the best thing the URL Requester can do is start at your $HOME.

Sure, the problem is that relative path is not supported now while it WAS
supported before.

> I can fix this so whatever is set as builddir is prefixed upon project
> opening for the executable line.

The build dir should be prefiex when executing, and the build dir should
be used in the url requester dialog as well if the path is not an absolute
path.
If it's an absolute path, there was and is no issue.

> That is indeed weird, but I know where it comes from. If the executable
> is not absolute we use the project directory to make it an absolute
> path. And I guess we should rather use the buildDirectory instead. I'll
> change that too, although with the change mentioned above we'd have an
> absolute path anyway, always.

Thanks!

> I hope after the last changes from today kdevelop should be as flexible
> as it was before, just that the way to set things up is now a bit
> different.

I'm not at home, but as soon as I get there, I'll update KDevelop again.

>> F7: an error "There is no Makefile in this directory" appears, and it
>> seems that it tries to start gmake in several subdirectories of the
>> project, like
>> cd '/data/development/build/kde-3.5/kdewebdev/quanta/utility/' &&
>> UNSERMAKE="no" WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake
>> libutility.la
>
> I can confirm this, but this cannot have worked before. We didn't change
> the code relevant to building the active target.

It might be that it didn't work before, as I never used make active target
for the Quanta project as there was no need. I just tried now, as the idea
was that every am project should have an active target and it failed.

> However I'll fix it. Though see below for a better way to achieve what
> you want while not using this "untested" and "by accident working" type
> of layout you currently use.

I like to test uncommon things. ;-)

> I do understand the project setup and we just "didn't think about it"
> when we re-designed the run-mess. Neither me nor Jens are AM experts and
> it didn't occur to use that the project dir might be a subdir beneath
> the top-source dir.

Yes, this can be and it works except the active target building.

> As for making the other kdewebdev subprojects "invisible", there's an
> Automake feature to do that: Add a file called inst-apps to the
> top-level directory and add all application subprojects you want to see,
> i.e. quanta in this case.

I didn't know about this. So KDevelop will ignore (in the classview for
example) all other subprojects that are not in the inst-apps?

>> you mean the Working Directory setting in the Target Options? That isn't
>> used when you Run the project, as I pointed above.
>
> It is used when Executing the Project via F7. It wasn't used earlier
> when executing the selected target via the small button in the AM.

I'll test this again.

> I hope with the changes I just committed it is not needed anymore,
> except when you work on a library. And in that case one will get a hint
> upon project execution where this setting is and that it might be needed
> to be set.
>
> Last but not least: Thanks for your input, I could fix a couple of
> things along the way which where broken and we are now aware that the AM
> actually supported this "strange" project layout.

Thanks also from my side for your work on this. :-)

Andras