where is the gccoptions dialog in gideons code ?

[W. Tasin]

Hi Otto, hi *,

your plans sounds really good, unfortunately I have little time to help 
you *doublesigh*...
but if I get some time I will help you of course (hope this will happen 
soon).

Otto Bruggeman wrote:

>>In general, any part can plug into the project options dialog by
>>doing
>>
>>  connect( core(), SIGNAL(projectConfigWidget(KDialogBase*)),
>>           this, SLOT(projectConfigWidget(KDialogBase*)) );
>>
>>and implemententing the slot, which gets the dialog as argument.
>>The dialog is a KDialogBase with any number of pages.
>>
>
>Ah thanks for the explanation, i'll move the code in the autoproject dir
>then and provide a cvs diff to catch all my stupid mistakes :) when i am
>ready with the code before i commit.
>
>There are a few ways to insert the macros into the buildsystem:
>- - Put it in a <appname>.m4.in file and put that with aclocal.m4.in and
>acinclude.m4.in into acinclude.m4. This requires a Makefile.am rule and
>some code in the project wizard to change the <appname> into the real
>name in the top Makefile.am.
>- - Add it to either aclocal.m4.in or to acinclude.m4.in (i need some place
>in the file where i can safely add the macros without interfering with
>other stuff and finding them back later). This avoids changing rules in
>the Makefile.ams
>

I would suggest the following:

- I don't believe in a file called aclocal.m4.in ;-)
aclocal.m4 is something which is created by configure.in and 
acinclude.m4 and other .m4 files of your system (/usr/share/aclocal) 
done by the aclocal-call, AFAIK nothing like aclocal.m4.in in between.
Using aclocal as base name would confuse people (at least me ;-))
So agree with you using solution 1.

- I personally would make a kdevprojects.m4.in (for the macros which are 
not kde-specific or would be in conflict with acinclude.m4.in from the 
kde-guys, published with kdevelop) and special.m4.in (created by the 
kdevelop user). I wouldn't be quite sure if this should be project 
specific or user specific. I guess user specific would be better, 
because a kdevelop developer doesn't write many m4-macros, but wants to 
find his macros already written in $(HOME)/.kde(2|3)-directory. On 
project creation time it would be copied inside the project directory 
and apart from updating the auto-framework (i.e. admin-dir), 
kdevproject.m4.in can be updated, too. Maybe also the special-m4-file 
from the user, which can be found in his home dir. That's MHO and 
request for discussion.

So my suggestion would be not to use <appname>.m4.in or 
<projectname>.m4.in, but a project independant name.
Another (not so important) reason: the make-rules inside the admin-dir 
allows to change only the name of the toplevel-directory and the whole 
project is renamed. Step by step we should go away from the 
appname/project-specific filenames in the toplevel directory. The less 
we find there the app-/projectname in a filename the better it would be.

pros: The rule inside $(toplevel)/Makefile.am would be always the same 
(even if kdevprojects.m4.in and special.m4.in are empty files)
cons: The kdevprj-files will contain the project name anyway.

acinclude.m4.in shouldn't be modified by the kdevelop developer (because 
it would corrupt any admin-dir-update) and kdevproject.m4.in is the same 
for all kdevelop project types (shouldn't be modified by kdevelop users 
- only if the macro-usage would be useful for all users ;-)).

These are my two euro-cents

Walter

-- 
The KDevelop project: tasin at kdevelop.de [www.kdevelop.org]
--
oohhh sveglia.... il mondo e' ammalato, ma x colpa di chi.........
(Zucchero)
:-------W. Tasin, FB 04,FHM-------------------PGP-KeyID:0x7961A645----------:
<Key-Fingerprint: 1610 835F 0080 32F4 6140  6CF7 A7D0 44CD 7961A645>