Make target settings are behavior incompatible

[Andras Mantia]

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?

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

> > Also in that case the Build Project action should be removed and
> > replaced with the Build Active Project.
>
> Huh? Build Project builds your whole project. If you want to build
> only a subproject or target there context menu actions for that as
> well as buttons on the project managers.

I know, this was the original idea. But if for an AM project the main 
program is not relevant, the two actions are basivly the same (unless 
you have a more complex project). Anyway, forget this.

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

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. (BTW, 
why I cannot copy text from the  Application output?)

Also if the following is used, when trying to pick up a directory for 
the executable, the file dialog starts from my $HOME. Really, just try 
it. KDevelop and the whole KDE was built last night.

> Hehe, we don't care about old users, those will find their way
> through the maze ;)
Sure, but they will be upset and rightfully.

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

So we have two cases:
1) Main program is disabled. This is what happened when I load my old 
project. Now:
F8: 
cd '/data/development/build/kde-3.5/kdewebdev' && UNSERMAKE="no" 
WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake 
*** Success ***
This is OK, it builds the project from the top build dir.

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'd expect to do a 
cd '/data/development/build/kde-3.5/kdewebdev/quanta/src' && ... gmake
instead of cd-ing in several dir and trying to build there. It is also 
unclear why I get the error message, as the project was already 
configured and there are Makefile-s in the build directory. So this is 
broken. 
Explicitely makeing this target active results in the same behavior.

Run: 
/data/development/build/kde-3.5/kdewebdev/src/quanta
/bin/sh: /data/development/build/kde-3.5/kdewebdev/src/quanta: No such 
file or directory
Exited with status: 127

Indeed, no such file or directory, as a "quanta" is missing between 
kdewebdev and src. It should look 
like /data/development/build/kde-3.5/kdewebdev/quanta/src/quanta

Changing the working directory for the active target to the current one 
doesn't help, as the problem here is the build directory.

About the project setup itself. The module is kdewebdev, contains 
several applications and one library (which is static). This is in 
kdewebdev/lib. The project I'm using is Quanta, and it is in 
kdewebdev/quanta. As the automake files are in the module directory, 
the top source and build is point to the main kdewebdev, but as I work 
only on Quanta, the directories in the automake manager are 
only "quanta" and its subdirs (not the whole kdewebdev and subdirs), so 
I'm not seeing the unrelated classes and files from the other kdewebdev 
projects. 

Conclusion: with main program disabled and the active target set to the 
main executable building the project is possible, building the active 
target gives error and running the executable is not possible. (Execute 
target from the context menu works though.)

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

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

Final conclusion is that the idea to reduce the number of needed 
configuration options was not successful as main program is still 
needed.

> For example before our changes 
> there wasn't really a hint that without anything in the executable
> and arguments lines the AM would take the settings for the currently
> active target.

I don't question the usefulness of the "Main Program" checkbox (in some 
cases it might really not be needed), I questioned the broken behavior 
of the paths and the fact that when loading an existing project this 
setting is disabled by default ebem if it had an executable specified.

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

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

> > My assumption of how it should work is:
> >
> > 1) if Main program is activated in the project and Executable is a
> > relative path, the path is appended to the build directory, F8
> > (Build Project) builds and runs this executable,
>
> F8 never started the build, so this won't happen, ever.
Sorry, I wanted to write "Execute Program" there.

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

Andras



-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070107/40aa58f1/attachment.sig>