I have a favour to ask

Amilcar do Carmo Lucas amilcar at ida.ing.tu-bs.de
Fri Jun 27 11:23:07 UTC 2003


Ian Wadham wrote:

>Thanks very much for your help in this, Amilcar.  You
>have given me a lot of ideas and it will take me a while
>to digest them all and try them out.  Thanks and thanks again ...
>
>A couple more questions, if you have the time ...
>
>  
>
>>>I don't know if it is a feature of "make" or just a tradition
>>>(which is also hallowed by KDevelop), but it looks as though
>>>all the Make and config stuff has to be mixed up in the same
>>>directories as your source code, icons, images, documentation
>>>and LSM file.  What I would like to do is have:
>>> 
>>>      - Separate directory structure for source code, doc, etc.
>>>      
>>>
>>src only gets a .cpp .h .ui .moc and Makefile.am and Makefile.in
>>
>>    
>>
>I was looking for a directory structure maybe like this:
>
>    $HOME/<my application subpath>
>         src
>               *.h and *.cpp (only)
>  
>
Sorry, but as far as KDevelop3 goes, you need to distribute your 
Makefile.am file here.
There is already a whish to change this, but I don't know when/if it 
will be implemented
See:  http://bugs.kde.org/show_bug.cgi?id=54998

>               docs
>                      en
>                            *.html and *.png (or *.htm for MS Win compat)
>  
>
Do you know that Doxygen generates: html, htm, TeX, RTF, Man, XML ...  :)
So this is possible TODAY :)

>               data
>                      *.dat (only)
>
yeap I think this one is also possible

>         KDE3version
>               KDevelop files, directories, makefiles, .o, etc. for KDE3
>               .kdevprj (or .kdevelop) file for KDE3
>
>         Qt3version
>               KDevelop files, directories, makefiles, .o, etc. for Qt3
>               .kdevprj (or .kdevelop) file for Qt3
>
Sorry but these two go together into the root of the project and into 
the admin directory.
And you only need one .kdevelop file that was two targets: a QT3 and a 
KDE3 target
Everything else would be overcomplicating I think

>
>where "src", "docs/en" and "data" contain NO Makefiles and
>the .kdevprj (or .kdevelop) files have different version text,
>different project type and other different options.
>  
>
They can have different options within the same project, no prob.
AFAIK docs/en has no makefile

>Why? I do not want to have to regenerate and  overwrite
>the makefiles, including maybe the Makefile.am, every
>time I switch between editing, testing, committing or
>distributing the two versions.
>
The Makefiles don't need to be regenerated! The same set can be used for 
both versions

>  Mistakes can happen that way
>--- timewasting for me, but REALLY nasty if they occur
>during a commit or distribution and I give people the wrong
>config and makefiles.
>
And do not forget you do NOT distribute the .kdevelop file!

>
>There's a symbol called $(topsrcdir) in the
>generated makefiles.  Could I use that somehow?  Or can the
>"subdir"s files have symbolic or ".." type paths in them?
>Do the makefiles really HAVE to be in the same subdir
>as the source you are compiling or the data, docs and
>source you are committing or distributing?
>  
>
Like I said it will probably not be necessary in the future but 
currently they have to be there.

>  
>
>>you need to access the repository
>> to do diffs and reverts.
>>
>>    
>>
>Only for CVS diffs and reverts.  I was thinking in terms
>of local "diff" (as in "man diff") to see what I have
>changed and "cp" commands to manually revert, in case
>I accidentally delete stuff or write junk code based
>on a misunderstanding of the Qt and KDE class
>libraries.  I am still learning to use those libraries.
>
>That's why I don't feel comfortable editing inside my
>kdenonbeta "sandbox" directory structure.  But I'm
>an old UNIX pro and have scripts to work out and copy
>what needs to go back into the sandbox when I am
>ready to do a "commit".
> 
>
You could try to do:
Copy the repository to your own PC
Do the complete development "in house"
Only distribute the results.

The problem with this approach is: Is your harddrive fails, you lose 
everything.
 

>  
>
>>Hope this helps,
>>
>>    
>>
>Yes, it certainly did ! ... Thanks, Amilcar ... :-) ...
>All the best, Ian W.
>  
>

I know some of the answers are not the one you would like to hear, but 
currently
that's just the way kdevelop works.

-- 
Amilcar Lucas








More information about the KDevelop-devel mailing list