The 'make package_source' problem was related to this diff.
Erik
--
http://www.adalin.com
- Hardware accelerated AeonWave and OpenAL for Windows and Linux
diff --git a/CMakeLists.txt b/CMakeLists.txt
index f6dd5fe..615b82e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -42,7 +42,7 @@ if (N
Maybe something has already been tweaked between v2.8 and v2.10. After I
manually removed the simgear/version.h file it did not come back again --
so maybe we will be in good shape for future releases.
I noticed that simgear/version.h (along with all the other build time
files) are explicitely li
On 18 Feb 2013, at 15:10, Erik Hofman wrote:
>> You seem to be correct, when doing a make package_source I see
>> simgear-2.11.0/build/simgear/version.h
The tar balls created by Jenkins (Linux-release) seem to be fine. They contain
version.h.in, but no version.h
They're created by the followi
Sorry Curt,
but nothing writes into the source dir if you use a sane, clean and
proper checkout from git. Your tarballs make me think that you already
ran cmake inside the source dir prior to packaging them. Could you run
"git clean -fdx" inside the source dir and tar the result up again?
This
On 02/18/2013 04:08 PM, Erik Hofman wrote:
> On 02/18/2013 04:04 PM, James Turner wrote:
>> Hmm, I don't think it matter *how* you write the file: PROJECT_BINARY_DIR
>> seems like the correct place based on my understand of cmake. I could be
>> wrong of course, but it makes more sense to me than
On 02/18/2013 04:04 PM, James Turner wrote:
> Hmm, I don't think it matter *how* you write the file: PROJECT_BINARY_DIR
> seems like the correct place based on my understand of cmake. I could be
> wrong of course, but it makes more sense to me than CMAKE_CURRENT_SOURCE_DIR.
You seem to be correc
Ok that got tangled up. Here's a diff.
Erik
--
http://www.adalin.com
- Hardware accelerated AeonWave and OpenAL for Windows and Linux
diff --git a/simgear/CMakeLists.txt b/simgear/CMakeLists.txt
index b4e299a..0725a78 100644
--- a/simgear/CMakeLists.txt
+++ b/simgear/CMakeLists.txt
@@ -1,5 +1,7
On 18 Feb 2013, at 14:57, Erik Hofman wrote:
>
> I see that simgear/CMakeList.txt defines:
>
> file(WRITE ${PROJECT_BINARY_DIR}/simgear/version.h "#define
> SIMGEAR_VERSION ${SIMGEAR_VERSION}")
>
> it would be better to create a version.h.in file and use
>
> CONFIGURE_FILE(
> "${CMAKE_C
On 02/18/2013 03:36 PM, Curtis Olson wrote:
> Ok, I see now that in simgear-2.10.tar.bz2 the top level file "version"
> does report 2.10.0 but the simgear/version.h file is saying 2.8.0
>
> So my question are:
>
> 1. for an out-of-source build, why is the build system writing files in
> the source
Ok, I see now that in simgear-2.10.tar.bz2 the top level file "version"
does report 2.10.0 but the simgear/version.h file is saying 2.8.0
So my question are:
1. for an out-of-source build, why is the build system writing files in the
source tree? Can we fix that?
2. what is the proper cmake fix
Hi Christian,
I completely blew away my "build_flightgear" and "build_simgear"
directories so they should be totally clean for the latest version of the
source code. Are our cmake rules doing something they shouldn't and
writing files in the original source tree when you do out of source builds?
Curt,
I noticed the SG/FG packages got updated on the mirrors. So I checked
them out again: still the same issue. How did you create the source
tarballs? Having the version number 2.8 in it looks like they were
created from an older, used git clone and not a fresh or cleaned up
one. The tarbal
Certainly this is my fault, however, I must misunderstand something about
cmake for this to happen. Can someone enlighten me and tell me what I need
to do to fix this? Maybe there is something we can tweak in the future if
the default behavior requires manual intervention to achieve the correct
o
Hi,
upon further inspection the problem appears to be more serious: It
occurs if SG/FG are built in a separate build dir, as recommended by
the cmake process. We then have version 2.8 in the original sources and
2.10 in the build dir. Why 2.8 gets picked up is beyond my knowledge
but I would c
Hi,
while this might be a minor issue, I still want to bring it up here:
The SG and FG 2.10.0 release tarballs from the ibiblio mirror contain
version.h files with version number 2.8.0. While this should be
overwritten by cmake on configure time I just experienced a case where
it wasn't with t
Hi Everyone,
I just wanted to send a quick update on the release process. Feb 17
arrives at different times at different places and it is still Feb 16 here
for another hour. I have uploaded the source and the mac version of the
release to ibiblio.org and the final windows version is being upload
Hy Yves
Sorry, I do not understand your question. Could you clarify, please?
Torsten
Am 16.02.2013 00:17, schrieb ys:
> Hi Torsten
>
> What does mean "no public answer" in this list for this decision ?
>
> -Yves
>
>
>
>
> Am 15.02.2013 um 16:16 schrieb Torsten Dreyer :
>
>> Hi all,
>>
>> at one p
Hi Torsten
What does mean "no public answer" in this list for this decision ?
-Yves
Am 15.02.2013 um 16:16 schrieb Torsten Dreyer :
> Hi all,
>
> at one point during every ILS approach you reach the decision altitude
> with two options: "continue approach" or "go around". Being the copilot
I would just add a quick last minute request to the developers (or anyone
else). We haven't organized an effort to collect screen shots for the
v2.10 release yet and I'd like to do that now. If anyone is
interested/willing to submit v2.10 screen shots (based on the release
candidates or other pre
Hi all,
at one point during every ILS approach you reach the decision altitude
with two options: "continue approach" or "go around". Being the copilot
on our approach into the 2.10 release, I'd call out "minimum, approach
lights in sight, continue!"
If no one shouts out loudly _NOW_, I'm going
20 matches
Mail list logo
