C/C++ projects don't work for suse 7.2, suse7.3 and upcoming kdevelop 2.0.2

[W. Tasin]

  Markus Kuehni wrote:

>Yeahh, I see.
>It's always like that in computer science. First you think it's "just easy"
>then point by point you uncover the exceptions, the exceptions to the
>exceptions and so on...  ;-)
>
yepp...

>
>Basically, I think what you are telling me, is that far too many developers
>really *need* to change the auto* stuff manually and the simplified "stream
>line" mode I suggested would only help a small fraction.
>
Basically I would say:
in the project creation time everyone will be happy, if the application 
compiles without errors :-)
in the feedback time (bug reports, new releases, etc. ) you need to 
change also some stuff inside the Makefile.ams and 
configure.in(.in|.mid|.bot) or in some cases develop some .m4 macros.
;-)

>
>>Now let's talk about the developer which doesn't change the
>>configure.in.in or a Makefile.am and wouldn't insert his own m4-rules,
>>so IMHO I don't need a changement in adding an additional  /mode/ or
>>/option/ an update function does the same (it is possible to do it with
>>the additional mode, but it isn't necessary - the bare bone tar could
>>also contain the auto* stuff to have the same tarball for the user which
>>install it by console and the one who use it with kdevelop and invokes
>>the update function).
>>
>>The update is "simple":
>>
>
>Cough, cough...
>
really? ;-)

>>remove all "old" auto* stuff, untar the admin directory, untar the
>>toplevel directory of the project template change the templates with the
>>substitutions (version number, name, etc.), scan the subdirectories and
>>recreate the Makefile.am completely new (with the help of *.kdevprj) and
>>use the stuff additionally set in *.kdevprj, add the new admin directory
>>to *.kdevprj.
>>
>
>Hmmm.. now, what I don't know is are you talking about a function that
>exists already?
>
AFAIK the only function that exists is the creation of the Makefile.am's 
and for using it apart from the project creation time this would have to 
be modified a little bit.
The rest is TODO.

>
>Or do you mean the user would have to do this step by step?
>
>
>>That's it and you would need the same function in your
>>concept.
>>
>
>Yes, and if this function already does exist (and I can invoke it through
>the GUI) then there is nothing else on my wishlist ;-)
>
If there were an automated version, we wouldn't have this thread :-)

>>You will loose the manually added flags in Makefile.am and all manual
>>changements of configure.in.in (CXXFLAGS, *_LIBADD, AM_*FLAGS, etc.),
>>but the developer who knows about the stuff could replace it manually,
>>right?
>>
>
>Exactly right.
>The question is "how many developers are auto* hackers, how many are not"?
>
Or better: how many developers should be auto* hackers and how much can 
we manage it, that a developer hasn't to be an auto* hacker.

>
>One question here: could this be done in an "additive" way?
>
Without parsing facilities? [Or maybe another solution would be the 
plugin system, didn't thought of this]
hmmmm... only if we all accept compromises (like: "in this stage only 
for users which haven't changed sth. inside configure.* or in the 
NON-kdevelop-specific parts of Makefile.am's).

>
>I mean instead of tweaking one global file (and afterwards not being able to
>distinguish user code from kdev-generated code) one could introduce a new
>file extension (say .konf). The filename could contain a number (e.g.
>sendmail.2.konf) to indicate ordering (similar to the init rc stuff).
>
>
>
>Each time KDevelop detects a change in .konf files, it
>
>1. generates a pristine configure.in according to the project template and
>does the magic on it (as it does when you create a new project)
>
>2. scans for .konf files (in the project registry) and copies their contents
>to certain parts of configure.in according to the number in the name
>
>This way auto* hackers could still write their own stuff and better yet
>could distribute their work to others. If I needed to check for sendmail one
>day I could probably get your sendmail.2.
>konf and just copy/register it to
>my project ;-)
>
Wow... that's what I meant with the conceptual change of project management.
An updating system, which has to be maintained and updated all the time.

The realisation is another topic.
Like I can also imagine instead of introducing another file extension I 
also could use comments inside the .m4 macros or a description file of 
all the macro functions and what they are doing (API reference for .m4 
calls)... puhhh...

An example:
acinclude.m4.in:
----
dnl
dnl name: AC_FIND_FILE
dnl param: $aFiles, $aDir, $result
dnl description: tries to search a file named inside the array [$aFiles]
dnl                     in one of the directories named inside the array 
[$aDir]
dnl                     save the occurance combination of $aDir/$aFile 
inside $result
dnl                     gives NO to $result if no file is found
dnl return: $result 
dnl req-lang: c, c++
dnl projecttypes: c, c++, qt, kde
dnl requires:
dnl invokes:
dnl pos_before:
dnl pos_after:
dnl input_env:
dnl output_env:
....

dnl
dnl name: KDE_USE_QT
dnl param: [$version, [$msg_string, [$define_string]]]
dnl description: specifies the version of qt which is required for the 
project.
dnl                     all parameters are optional.
dnl                     ....
dnl return:  
dnl req-lang: c, c++
dnl projecttypes: qt, kde
dnl requires:
dnl invokes:
dnl pos_before: KDE_PRINT_QT_PROGRAM, KDE_CHECK_QT_DIRECT, AC_PATH_QT_1_3
dnl pos_after:
dnl input_env:
dnl output_env:
...

dnl
dnl name: AC_PATH_QT
dnl param:
dnl description: invokes AC_PATH_QT_1_3
dnl                     which is for testing the presence of qt includes 
and libs
dnl                     ....
dnl return:
dnl req-lang: c++
dnl projecttypes: qt, kde
dnl requires: K_PATH_X, KDE_USE_QT, AC_FIND_PNG, AC_FIND_JPEG
dnl invokes: KDE_PRINT_QT_PROGRAM, [KDE_CHECK_QT_DIRECT,] AC_PATH_QT_MOC_UIC
dnl pos_before: KDE_CHECK_QT_DIRECT
dnl pos_after: AC_CHECK_COMPILERS
dnl input_env: $LIBQT_GLOB, $LIBQT, $QTINC, $QTLIB, $all_includes, 
$all_libraries, $x_libraries,
dnl output_env: $qt_includes, $qt_libraries, $QT_INCLUDES, $QT_LDFLAGS, 
$LIB_QT, $kde_qtver

etc. etc. ....

I don't know if these are all informations, which are necessary or if it 
is a little bit exaggerated but it is a beginning *g*.
Of course changing pos_before and pos_after to a numeric value as you 
mentioned before would make it easier, but this should show you only, 
what has to be considered IMHO.

I think the same (or almost the same) would happen to the .konf files.

>
>The same could be done for .am fragments in their respective directories.
>The following is not to be take serious: We could name these .kake as in
>"Kdevelop automake konstruction entry" or "piece of [the] cake" ;-)
>

If there is somebody who can maintain the .konf or .m4 files and has 
written the code for doing the stuff described above, so the handling of 
the round about 20 different possibilities of Makefile.am entries can 
also be done (at least I hope so ;-)).

I think the update wouldn't occur as much as in the .m4 part and I think 
the handling of Makefile.am isn't so difficult as the handling of the 
macro calls, but needs also thoughts like you did (and still much work 
[before you'll say again "caught, caught" ;-)])

>
>
>Often-used and well tested fragments could then be distributed with KDevelop
>and even given a checkbox in the project settings GUI.
>
Unfortunately this can't always be handled by only a checkbox, see 
KDE_USE_QT which can have 0, 1, 2 or 3 parameters.
Maybe the solution is the plugin system of gideon as mentioned above, 
i.e. one gui-plugin for the settings of one m4 call?! I don't know...

>
>
>Ciao.
>
>-- Mark
>
>
>-
>to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
>unsubscribe »your-email-address«
>
Ciao

Walter

-- 
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>
<http://wwwkeys.pgp.net:11371/pks/lookup?op=index&search=0x7961A645&fingerprint=on>





-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«