Make target settings are behavior incompatible

[Andreas Pakulat]

On 07.01.07 11:20:29, Andras Mantia wrote:
> Hi,
> 
> On Sun Jan 7 2007, Andreas Pakulat wrote:
> > For AM there's _always_ an active target, AFAIK. At least there's no
> > Ui to unset an active target.
> Hm, if you just create a new project does it automatically set something 
> (what?) to be the active target?

I didn't test all of the various templates, but at least the KDE
templates that create an application all set the main binary as active
target. 

But I have to admit I was wrong. There were at least 2 possibilities to
end up without an active target. The first beeing "Import existing
project", that template doesn't set an active target. The other way was
to remove the current active target from the subproject.

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.

Same thing if the active target is a library, I added a msg box for that
too, which suggests to activate the main program in Run Options.

> > > What you say results in fact that every time an active target MUST
> > > be defined and than this Main program setting is just superfluous
> > > and must be removed.
> >
> > Well, for AM/QM it is superflous, thats why its disabled by default.
> > However the same dialog (code-wise) is used for all other project
> > managers and those don't have targets or subprojects.
> 
> Ok, I admit I was only using am projects, so I didn't know that there 
> are projects which have less functionality, like no active targets.

:) 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/

> > > > It uses the project managers buildDirectory() value,
> > > > whatever the project manager returns for that.
> > >
> > > Something is broken than...
> >
> > Not for me. What project manager do you use?
> 
> Automake. See my values:
> Top source: /data/development/sources/kde-3.5/kdewebdev
> Build directory: /data/development/build/kde-3.5/kdewebdev
> Working directory: /data/development/build/kde-3.5/kdewebdev
> Executable: quanta/src/quanta

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.

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.

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.

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

> In previous KDevelop versions this executed 
> /data/development/build/kde-3.5/kdewebdev/quanta/src/quanta
> (build + executable)
> And this is what I'd expect. Now it tries to run:
> 
> /data/development/sources/kde-3.5/kdewebdev/quanta/quanta/src/quanta
> 
> This is top source + quanta + executable. I have no idea from where the 
> middle  "quanta" comes, but I find this to be wrong from start.

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.

> (BTW, why I cannot copy text from the  Application output?)

Heh, I had the same problem some time ago and the response from the
other developers was: the widget that is used for app output allows
filtering but no copying. We could use another widget for it, but then
we'd have no filter :(

> > Seriously though, this is an attempt to have less places for the
> > different options and to simplify it.
> 
> I don't question the attempt and the goal, but the result. ;-) There 
> aren't less places for the options, they are exactly the same number of 
> options. Just that the behavior is now incompatible with the previous 
> version. 

Well, actually there is 1 place less to set stuff as we incorporated the
debugger-arguments into the run options or target options.

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.

> Let's take again a look at the automake project. It's simple in a way 
> that there is only one target, the main executable called "quanta". 
> Altough it's not clearly marked, I assume that the bold text in the 
> Automake Manager indicates that it is the active target. (it is 
> quanta/src directory, quanta/src/quanta target under the top source 
> dir)

Yes, that is the AM's way of telling you the active target, I think this
is also documented in the handbook. Also the corresponding subproject is
bold too.

> So we have two cases:
> 1) Main program is disabled. This is what happened when I load my old 
> project. Now:

BTW your layout is IMHO a bit "strange" for kdevelop, as the top-level
source dir is not the top-level project dir (which is the quanta subdir)

> 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.

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.

> About the project setup itself.

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.

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.

> 2) Main program is enabled.
> 
> F8: works, builds the project.
> F7: same error as above
> Run: works if I use the absolute path to the executable, fails otherwise 
> as I described

Yeah, the wrong dir is prefixed to the main program when its not an
absolute path.

> Conclusion for me is that main program is needed for (some) automake 
> projects as well...

Not anymore (I hope) as of Revision 620799.

> > > > b) didn't work properly with all project managers
> > > > c) spread the settings over different pages in the Ui
> > > > d) didn't work properly in the project manager it was designer
> > > > for, i.e. automake.
> > >
> > > See the first part. Now it is *really* confusing, especially why it
> > > tries to start from the source directory.
> >
> > It doesn't for me. It starts from whereever I set it to via the
> > targets Options dialog (last tab).
> 
> 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.

> > Although I today fixed a small problem, where the "Execute target"
> > button in the lower part of the Automake manager would always run
> > from the builddirectory of the target.
> 
> Execute target works. Execute Program (Shift-F9) doesn't.
> 
> > > This would be logical, just running the active target is not that
> > > clear, if this is not an executable. Think about developing a
> > > complex application, like KDevelop, when you might make the active
> > > target a library you work on, still to test it you want to execute
> > > the main program, not the active target.
> >
> > Hmm, you have a point here. Although you can set the main app in the
> > run dialog to achieve this.
> 
> So as I also pointed out, this setting is important, yet it is ignored 
> unless you explicitely enable 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.

Andreas

-- 
You definitely intend to start living sometime soon.