yade-dev team mailing list archive

[Václav Šmilauer <eudoxos@xxxxxxxx>]

> Yes, I noticed that *.kdevelop and *.pro files disapeared... ;-). I 
> didn't think it was a permanent situation.
> I'll try to visit the wiki on Scons-Kdevelop if i've time, which is not 
> very sure...
> 
> The most important question is, how do i add a new class to Yade now? 
> I'm used to include the new classes in pro files by hand (not using 
> kdevelop then...), which is very easy. How it will work without pro files?

Good question. I wanted to document that somewhere on a wiki or in 
documentation files. This is just a quick write-up:

1. If your class is out-of-tree, use pkg-config for compilation. I suppose 
that it is not your situation...

2. If you want to integrate it to yade tree:

2a. Decide where it should go (lib, core, pkg/dem, pkg/..., extra).

2b. Find file calld 'SConscript' there (in lib, core, pkg/*) etc. There is 
about 8 of them for whole yade. These files contain the meat of what is 
compiled, how, etc.

2c. You will see env.SharedLibrary statement for each plugin that exists 
already. Pick any of them, cut&paste.

2d. Parameters are: target, sources, the rest. You need to change
  * target, i.e. plugin name - resulting file will be lib*.so
  * sources - may be multiple, like ['dir/file1.cpp','dir/file2.cpp'], or 
just one (most plugins). The path is relative, from the directory where the 
SConscript file lives. Other plugins will show you.
  * in the rest, you will probably have to specify which LIBS you want to 
link with. Do that as most plugins do:
   - LIBS=env['LIBS']+['lib1','lib2','lib3']. This will append lib1, lib2 
and lib3 to the default list of libraries inherited from env (those are Wm3 
and a few other).
   - you don't have to set CPPPATH if you use only #include"..." for files 
in the directory of the source file and #include<yade/core/...> etc. for 
different parts of yade. There is too much stuff now for CPPPATH (since it 
was auto-generated) and it looks too complicated).

2e. Check carefully that parentheses/brackets match!

2f. Compile: invoke scons from top-level dir.

Example:
env.SharedLibrary('plugin1',['plugin1a.cpp','plugin1b.cpp'],LIBS=env['LIBS']+['some','other','libraries']),

(note comma at the end: all env.SharedLibrary are arguments to Install 
(econd line of the file) and are comma-separated).

> In fact, why remove pro files at all? Is it really the plan? I thought 
> Vaclav used them for the scons build.
Yes, but it was only a temporary solution. Qmake is not nearly as flexible 
as we need - separated builds, suffixing binaries etc.

> One point raised in the past in 3S by Philippe Marin should be kept in 
> mind i think :
> "When you read SDEC code, you feel like it has been developped by a 
> mechanical engineer, and you understand the code. When you read yade 
> code, you feel like it has been developped by programmers, and you 
> understand nothing"
I agree wholeheartedly with that. But I think that the problem is in missing 
documentation. Once you get the idea how it works, it's not as difficult as 
it seems at the first sight.

> I would add : "when you try to _use_ Yade (and want to write few 
> classes), you feel like you have to learn linux first, waste hours to 
> install it, configure network, etc.,  learn a bit of bash, learn how 
> qmake, scons or whatever work, and a lot more things."

> This is why most people who really use DEM in 3S keep using SDEC or PFC 
> at the moment (PFC when they don't have to write code). And they are 
> developping a lot of things I'd like to see in yade rather than sdec 
> (membranes, clumps,...).
I hope developing yade will be _easier_ from this point on. We will see, 
though. For the installation, once we have packages for a few debian 
flavours, there should not be problem with installation any more. Janek is 
planning some changes (again), so I hope some sort of "stable" version might 
be ready before that happens...

> So one of my concerns with each change is : will I have to learn 
> something new? and will it become even harder to make my colleagues use 
> Yade.
> I think kdevelop is a good tool to help people start with yade with the 
> minimal background. But I'm sure Vaclav has this in mind already ;-).
I understand the concern. The objective is to balance short-term, hackish 
solutions and long-term changes. Of course you will have to learn something 
new, but hopefully it will not repeat every few months.


Hopefully, if you keep posting about things that are not evident, we will 
have useful documentation shortly.

Best, Vaclav
_______________________________________________
yade-dev mailing list
yade-dev@xxxxxxxxxxxxxxxx
https://lists.berlios.de/mailman/listinfo/yade-dev