setting up cmake builddirs

Hi,

currently for a cmake project one can configure multiple
cmake builddirs
via the project configuration. The dialog for setting up a
new builddir
forces the user to let cmake run before being able to close
it.

Now I just (as in the last couple of days) added
configure-support for
projects via the projectbuilder. This allows the
CMakeBuilder to run
cmake with a builddir+sourcedir fetched from the
project/buildsystemmanager. That in turn makes the above
enforcement
kind of obsolete - IMHO. 

So I'd like to move forward and do the following:

a) add an edit button to allow to change the following
things for each
builddir:
  - cmake binary
  - builddir
  - install prefix
  - buildtype
  - arbitrary cmake arguments

b) store that information in nested groups for each
builddir, those
settings override anything in the CMakeCache.txt when the
user runs
configure on the project

c) remove the "run cmake" stuff from the dialog
and add a note that
after creating a builddir the user needs to configure the
project

d) make sure the cmakecache.txt-model doesn't break down
when there's no
CMakeCache.txt file ;)

This means the workflow for creating a new cmake project (or
opening one
which doesn't have a builddir yet) would be:
project-configuration, add
a builddir with apropriate options, then run Configure from
the menu and
then you can build/install.

Objections? Better ideas?

Andreas

PS: The "guessing" of the cmake binary is not
cross-platform, but I
don't have a better idea right now (uses which cmake
currently).

-- 
Never be led astray onto the path of virtue.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Nov 11, 2007, at 6:32 PM, Andreas Pakulat wrote:

> Hi,
>
> currently for a cmake project one can configure
multiple cmake  
> builddirs
> via the project configuration. The dialog for setting
up a new  
> builddir
> forces the user to let cmake run before being able to
close it.
>
> Now I just (as in the last couple of days) added
configure-support for
> projects via the projectbuilder. This allows the
CMakeBuilder to run
> cmake with a builddir+sourcedir fetched from the
> project/buildsystemmanager. That in turn makes the
above enforcement
> kind of obsolete - IMHO.
>
> So I'd like to move forward and do the following:
>
> a) add an edit button to allow to change the following
things for each
> builddir:
>   - cmake binary

Why do you need to change this?

>   - builddir

This feature will need to check to make sure that the build
dir isn't  
already configured

>   - install prefix
>   - buildtype
>   - arbitrary cmake arguments
>

fine.

> b) store that information in nested groups for each
builddir, those
> settings override anything in the CMakeCache.txt when
the user runs
> configure on the project
>

No, the CMakeCache.txt needs to be the master document, so
to speak.  
So when we change those, we update the CMakeCache.txt file.


> c) remove the "run cmake" stuff from the
dialog and add a note that
> after creating a builddir the user needs to configure
the project
>

Yes for removing the run cmake stuff, no for telling the
user that  
they need to configure the project. We should just start
that as part  
of the build process when the user runs "build"
from kdevelop.

> d) make sure the cmakecache.txt-model doesn't break
down when  
> there's no
> CMakeCache.txt file ;)
>

I haven't run it yet (hardware issues) but what's broken
about it?


> This means the workflow for creating a new cmake
project (or  
> opening one
> which doesn't have a builddir yet) would be:
project-configuration,  
> add
> a builddir with apropriate options, then run Configure
from the  
> menu and
> then you can build/install.

Take out the Configure step and it sounds fine.

> Objections? Better ideas?
>
> Andreas
>
> PS: The "guessing" of the cmake binary is not
cross-platform, but I
> don't have a better idea right now (uses which cmake
currently).

we shouldn't be guessing it. cmake should be in the path.
We've  
required this for autotools and when we actually get around
to  
providing good automake support, i'm not going to be doing
any  
guessing, but requiring the person to tell us what automake
they want  
if they want something different from the default.
- --
Matt


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHN90BA6Vv5rghv0cRAu1FAKCg/0JSph0mqA+66Depel4RwwFtzACg
t2/r
p4YA9/UL8O8gjpinasQ4ZD0=
=1c4n
-----END PGP SIGNATURE-----

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 11.11.07 22:56:33, Matt Rogers wrote:
> On Nov 11, 2007, at 6:32 PM, Andreas Pakulat wrote:
> > currently for a cmake project one can configure
multiple cmake  
> > builddirs
> > via the project configuration. The dialog for
setting up a new  
> > builddir
> > forces the user to let cmake run before being able
to close it.
> >
> > Now I just (as in the last couple of days) added
configure-support for
> > projects via the projectbuilder. This allows the
CMakeBuilder to run
> > cmake with a builddir+sourcedir fetched from the
> > project/buildsystemmanager. That in turn makes the
above enforcement
> > kind of obsolete - IMHO.
> >
> > So I'd like to move forward and do the following:
> >
> > a) add an edit button to allow to change the
following things for each
> > builddir:
> >   - cmake binary
> 
> Why do you need to change this?

Because you're using different cmake's for different
builddirs, for
whatever reason (for example testing cmake cvs on your
project, or
trying to reproduce a bug or....)

> >   - builddir
> 
> This feature will need to check to make sure that the
build dir isn't  
> already configured

Hmm, why? A re-run of cmake usually doesn't break anything
in your
builddir.

> > b) store that information in nested groups for
each builddir, those
> > settings override anything in the CMakeCache.txt
when the user runs
> > configure on the project
> >
> 
> No, the CMakeCache.txt needs to be the master document,
so to speak.  
> So when we change those, we update the CMakeCache.txt
file.

Hmm, so the logic you want is something like:

if exists CMakeCache.txt do cd <builddir>; cmake .
else do cd <builddir>; cmake -DINSTALL_PREFIX
-DBUILD_TYPE <sourcedir>

right? (where the cd isn't really done, instead the working
dir of the
KProcess is set properly)

Would be fine with me.

> > c) remove the "run cmake" stuff from the
dialog and add a note that
> > after creating a builddir the user needs to
configure the project
> 
> Yes for removing the run cmake stuff, no for telling
the user that  
> they need to configure the project. We should just
start that as part  
> of the build process when the user runs
"build" from kdevelop.

Agreed.

> > d) make sure the cmakecache.txt-model doesn't
break down when  
> > there's no
> > CMakeCache.txt file ;)
> 
> I haven't run it yet (hardware issues) but what's
broken about it?

I didn't say anything is broken, that was just my weird way
of asking
wether the code that displays the files content also works
without the
file being there...

> > Objections? Better ideas?
> >
> > Andreas
> >
> > PS: The "guessing" of the cmake binary
is not cross-platform, but I
> > don't have a better idea right now (uses which
cmake currently).
> 
> we shouldn't be guessing it. cmake should be in the
path.

Read carefully, it does use cmake from path currently, but
the config
dialog tries to produce an absolute  path for cmake so the
user directly
sees which cmake he uses. The guessing done here is simply
running
"which cmake" and taking the output from that.

> We've  required this for autotools and when we actually
get around to
> providing good automake support, i'm not going to be
doing any
> guessing, but requiring the person to tell us what
automake they want
> if they want something different from the default.

I completely agree. I was just stating that "which
cmake" is not
portable, IIRC.

Andreas

-- 
You shall be rewarded for a dastardly deed.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 12.11.07 20:58:45, Aleix wrote:
> On Nov 12, 2007 1:32 AM, Andreas Pakulat <apakugmx.de> wrote:
> > currently for a cmake project one can configure
multiple cmake builddirs
> > via the project configuration. The dialog for
setting up a new builddir
> > forces the user to let cmake run before being able
to close it.
> >
> > Now I just (as in the last couple of days) added
configure-support for
> > projects via the projectbuilder. This allows the
CMakeBuilder to run
> > cmake with a builddir+sourcedir fetched from the
> > project/buildsystemmanager. That in turn makes the
above enforcement
> > kind of obsolete - IMHO.
> 
> I don't really see the problem with the current
solution to the problem.
> I understand that your proposal is to move the builddir
generation to the
> configure state. Isn't it?

Right.

> > b) store that information in nested groups for
each builddir, those
> > settings override anything in the CMakeCache.txt
when the user runs
> > configure on the project
> >
> > c) remove the "run cmake" stuff from the
dialog and add a note that
> > after creating a builddir the user needs to
configure the project
> 
> I understand that for you, configure  means running
cmake to create the
> builddir. I wonder why is it necessary to have both
steps splitted. Who
> wants a not configured build dir?

Probably few if any, the reason is putting the functionality
into 1
place, instead of many. And configure is the proper place,
for a few
reasons (IMHO of course):

- it doesn't block the user, the configure-cmake-run runs in
the
  background and the user can go on working on his code,
open another
  project or whatnot. While the run-stuff in the config
dialog makes
  this impossible (or is it non-modal, didn't check
actually)
- configure can be used when "pruning" the
builddir (i.e. rm -rf *), it
  would be quite a pain to have to go to project
configuration just to
  re-run cmake fully
- configure will be available anyway, if just to re-run
cmake which
  sometimes is necessary (think you noticed you miss an
optional
  dependecy for your project and now you installed it)

> > PS: The "guessing" of the cmake binary
is not cross-platform, but I
> > don't have a better idea right now (uses which
cmake currently).
> 
> 'which' is not cross platform, but the function
findFile I have (used in the
> project visitor) would fit our needs.

Was just a remark I wanted to get out when I saw the code
;)

> BTW, making the cmake support multiplatform (I am
thinking about Windows and
> MacOS X) would mean some new features that we don't
have available for now.
> For example, register features (Windows),

Huh? I think I don't understand. What has cmake support to
do with the
registry (I'm assuming that was a typo, or was it not?)

> usage of ; to separe paths in $PATH (Windows),

Uhm, do you read PATH somewhere?

> or Frameworks (Macos).

I'm not that familiar with MacOSX frameworks, but this would
only affect
the gui right? (and of course the generation of cmake
commands, which
would then use something different from
add_library/add_executable, or
some flag to those)

> Also, I am thinking that in the project configuration,
instead of choosing
> what modules directory to use, we should ask the binary
to use and
> extrapolate from there

I'm not sure this works reliably, especially on Linux (I
think MacOs,
but definetly Windows are less problematic here), where
distro's like to
put data files into various different places that you can't
easily
guess. And cmake doesn't provide a way to find that out -
AFAIK. We
should probably start a discussion about this on the cmake
list...

Andreas

-- 
You will be the last person to buy a Chrysler.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Monday 12 November 2007, Andreas Pakulat wrote:
> On 12.11.07 20:58:45, Aleix wrote:
...
> > BTW, making the cmake support multiplatform (I am
thinking about Windows
> > and MacOS X) would mean some new features that we
don't have available
> > for now. For example, register features
(Windows),
>
> Huh? I think I don't understand. What has cmake support
to do with the
> registry (I'm assuming that was a typo, or was it
not?)

You can read registry values in cmake under windows and use
them e.g. as paths 
used in the find_xxx() commands. find_package() also checks
the registry.

> > usage of ; to separe paths in $PATH (Windows),
>
> Uhm, do you read PATH somewhere?

Yes, e.g. find_program() uses it, and there are more env.
vars supported by 
cmake, and these env. vars have the platform specific
separators.

> > or Frameworks (Macos).
>
> I'm not that familiar with MacOSX frameworks, but this
would only affect
> the gui right? (and of course the generation of cmake
commands, which

It affects the result of find_library(), maybe also of
find_path/find_file 
(for headers, I'd need to check). Since the result from
find_library() 
probably affects the include directories, it affects e.g.
code completion.

Actually since any result can be used in arbitrary ways,
every result can 
affect everything:

if(some_lib_is_a_framework)
   include_directories(foo bar)
   add_executable(...)
   add_subdirectory(...)
   ...
else(some_lib_is_a_framework)
   ... do something else
endif(some_lib_is_a_framework)

> some flag to those)
>
> > Also, I am thinking that in the project
configuration, instead of
> > choosing what modules directory to use, we should
ask the binary to use
> > and extrapolate from there
>
> I'm not sure this works reliably, especially on Linux
(I think MacOs,

Yes, it works, that's how cmake itself finds its module
directory.

> but definetly Windows are less problematic here), where
distro's like to
> put data files into various different places that you
can't easily
> guess. And cmake doesn't provide a way to find that out
- AFAIK. We

message(STATUS "$")

Alex


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 12.11.07 21:47:21, Alexander Neundorf wrote:
> On Monday 12 November 2007, Andreas Pakulat wrote:
> > On 12.11.07 20:58:45, Aleix wrote:
> ...
> > > BTW, making the cmake support multiplatform
(I am thinking about Windows
> > > and MacOS X) would mean some new features
that we don't have available
> > > for now. For example, register features
(Windows),
> >
> > Huh? I think I don't understand. What has cmake
support to do with the
> > registry (I'm assuming that was a typo, or was it
not?)
> 
> You can read registry values in cmake under windows and
use them e.g. as paths 
> used in the find_xxx() commands. find_package() also
checks the registry.

Interesting, that adds quite some complexity I guess.

> > > or Frameworks (Macos).
> >
> > I'm not that familiar with MacOSX frameworks, but
this would only affect
> > the gui right? (and of course the generation of
cmake commands, which
> 
> It affects the result of find_library(), maybe also of
find_path/find_file 
> (for headers, I'd need to check). Since the result from
find_library() 
> probably affects the include directories, it affects
e.g. code completion.

Hmm, I wonder wether code-completion for frameworks is
easily possible
at all. After all if the headers are inside the framework
there's no
existing easy way to access them, unless you write
platform-specific
code.. Wow, this is going to be quite a bit more complex
than I
thought...
 
> > but definetly Windows are less problematic here),
where distro's like to
> > put data files into various different places that
you can't easily
> > guess. And cmake doesn't provide a way to find
that out - AFAIK. We
> 
> message(STATUS "$")

Aah, so thats a compiled-in value? Though a
commandline-switch to cmake
to retrieve that would be much easier to use than writing a
CMakeLists.txt to a temp dir and reading its output,
especially as even
the smalles cmake project produces more than just that
status line...

Andreas

-- 
Don't worry.  Life's too long.
		-- Vincent Sardi, Jr.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Nov 12, 2007, at 3:38 AM, Andreas Pakulat wrote:

> On 11.11.07 22:56:33, Matt Rogers wrote:
>> On Nov 11, 2007, at 6:32 PM, Andreas Pakulat
wrote:
>>> currently for a cmake project one can configure
multiple cmake
>>> builddirs
>>> via the project configuration. The dialog for
setting up a new
>>> builddir
>>> forces the user to let cmake run before being
able to close it.
>>>
>>> Now I just (as in the last couple of days)
added configure- 
>>> support for
>>> projects via the projectbuilder. This allows
the CMakeBuilder to run
>>> cmake with a builddir+sourcedir fetched from
the
>>> project/buildsystemmanager. That in turn makes
the above enforcement
>>> kind of obsolete - IMHO.
>>>
>>> So I'd like to move forward and do the
following:
>>>
>>> a) add an edit button to allow to change the
following things for  
>>> each
>>> builddir:
>>>   - cmake binary
>>
>> Why do you need to change this?
>
> Because you're using different cmake's for different
builddirs, for
> whatever reason (for example testing cmake cvs on your
project, or
> trying to reproduce a bug or....)
>
>>>   - builddir
>>
>> This feature will need to check to make sure that
the build dir isn't
>> already configured
>
> Hmm, why? A re-run of cmake usually doesn't break
anything in your
> builddir.
>

Because cmake will barf on us if we try to rerun it with an
already  
configured build dir but with different parameters, IIRC. I
could be  
wrong.

>>> b) store that information in nested groups for
each builddir, those
>>> settings override anything in the
CMakeCache.txt when the user runs
>>> configure on the project
>>>
>>
>> No, the CMakeCache.txt needs to be the master
document, so to speak.
>> So when we change those, we update the
CMakeCache.txt file.
>
> Hmm, so the logic you want is something like:
>
> if exists CMakeCache.txt do cd <builddir>; cmake
.
> else do cd <builddir>; cmake -DINSTALL_PREFIX
-DBUILD_TYPE <sourcedir>
>

> right? (where the cd isn't really done, instead the
working dir of the
> KProcess is set properly)
>

basically, although using the already existing
CMakeCache.txt parser  
(i think it exists) would be better. 

> Would be fine with me.
>
>>> c) remove the "run cmake" stuff from
the dialog and add a note that
>>> after creating a builddir the user needs to
configure the project
>>
>> Yes for removing the run cmake stuff, no for
telling the user that
>> they need to configure the project. We should just
start that as part
>> of the build process when the user runs
"build" from kdevelop.
>
> Agreed.
>
>>> d) make sure the cmakecache.txt-model doesn't
break down when
>>> there's no
>>> CMakeCache.txt file ;)
>>
>> I haven't run it yet (hardware issues) but what's
broken about it?
>
> I didn't say anything is broken, that was just my weird
way of asking
> wether the code that displays the files content also
works without the
> file being there...
>

that's a funny way of asking. 

>>> Objections? Better ideas?
>>>
>>> Andreas
>>>
>>> PS: The "guessing" of the cmake
binary is not cross-platform, but I
>>> don't have a better idea right now (uses which
cmake currently).
>>
>> we shouldn't be guessing it. cmake should be in the
path.
>
> Read carefully, it does use cmake from path currently,
but the config
> dialog tries to produce an absolute  path for cmake so
the user  
> directly
> sees which cmake he uses. The guessing done here is
simply running
> "which cmake" and taking the output from
that.
>

Well, we shouldn't be doing that either, since that's not
portable at  
all.

>> We've  required this for autotools and when we
actually get around to
>> providing good automake support, i'm not going to
be doing any
>> guessing, but requiring the person to tell us what
automake they want
>> if they want something different from the default.
>
> I completely agree. I was just stating that "which
cmake" is not
> portable, IIRC.
>
> Andreas
>

- --
Matt


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHON0fA6Vv5rghv0cRAjzbAJ9TKbrpcrezfSqHsl3NzeCQL3q72QCf
dxfZ
t7+JqL0pGadj/8J/sUouugk=
=wnVt
-----END PGP SIGNATURE-----

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 12.11.07 17:09:19, Matt Rogers wrote:
> On Nov 12, 2007, at 3:38 AM, Andreas Pakulat wrote:
> > On 11.11.07 22:56:33, Matt Rogers wrote:
> >> On Nov 11, 2007, at 6:32 PM, Andreas Pakulat
wrote:
> >>>   - builddir
> >>
> >> This feature will need to check to make sure
that the build dir isn't
> >> already configured
> >
> > Hmm, why? A re-run of cmake usually doesn't break
anything in your
> > builddir.
> 
> Because cmake will barf on us if we try to rerun it
with an already  
> configured build dir but with different parameters,
IIRC. I could be  
> wrong.

You are wrong  In fact
cmake will happily accept _at least_ BUILD_TYPE
and INSTALL_PREFIX being different from what is in the cache
and change
the cache values accordingly. Just tested this.

> >>> b) store that information in nested groups
for each builddir, those
> >>> settings override anything in the
CMakeCache.txt when the user runs
> >>> configure on the project
> >>>
> >>
> >> No, the CMakeCache.txt needs to be the master
document, so to speak.
> >> So when we change those, we update the
CMakeCache.txt file.
> >
> > Hmm, so the logic you want is something like:
> >
> > if exists CMakeCache.txt do cd <builddir>;
cmake .
> > else do cd <builddir>; cmake
-DINSTALL_PREFIX -DBUILD_TYPE <sourcedir>
> >
> 
> > right? (where the cd isn't really done, instead
the working dir of the
> > KProcess is set properly)
> 
> basically, although using the already existing
CMakeCache.txt parser  
> (i think it exists) would be better. 

Well, there's a regex-parser used in the model that displays
in the
config dialog. I guess this is one of the places where many
regexes are
coming from. This would probably be a bit faster with a
hand-written
parser as its a really simple syntax...

Anyway, I guess that would mean having either a shared lib
for manager
and builder (I assume the manager needs the cache-parser as
well, if it
doesn't we can just move the config-stuff to the builder) or
providing
an interface class for the cmake manager and let the builder
plugin
depend on it (would create a circular dependecy between both
plugins,
obviously - though that shouldn't be a problem I think)

Andreas

-- 
Don't go surfing in South Dakota for a while.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel