[mapguide-internals] Version setting script - What about ANT
vs CMAKE
UV
uvwild at gmail.com
Wed Apr 8 05:25:38 EDT 2009
yessss the cmake... what happened to it?
*
**CMAKE???*
I only read the intro for cmake so please correct my mistakes.
It seems very C/C++ centric which is limiting as there are also .NET and
JAVA elements to be handled for the frontend.
Also it seems directory based. Ant does not have this limitation and
can work across directories.... or call the build.xml in each directory
as you like.
I think this could be an important difference.
The examples for the cmake case are very simple ..... more complex
configurations might end up in hard to read complex cmake config files
also....
Ant uses XML files with documenting tags and this has a bit more structure.
*ANT for C++ BUILDS:*
There is an Ant extension by codemesh which provides a <CC> task which
know about the compilers. Not sure if its free though..
But lots of people are using ant for C++ builds. So there are lots of
examples in the net...
Without the cc tasks the compiler task can be configured as an
executable and this needs to be done explicitely for each platform.
(e.g. I found a page about how to call ccvars.bat to set the environment
for msvc compiler)
Multi-platform unfortunately does not save us from the need of providing
platform specific configuration like compilers....
The power of ant is its extensibility.... Also you can implement custom
tasks. You can build a file list very easy and apply commands to it.
So slapping in the version update (i.e. also the revision number into
the source files would be great) is easy in ant. /I think Cruise Control
also has a task for that!/
I dont know how well cmake handles this. Generally I found ant files
easier to handle than make files....
But to tell ant build the whole system is also a non-trivial task !*
*
*Cmake vs. Ant
*I think Cmake probably is the better C++ build machine for lots of
different *nixe.
For complex project configurations with a multitude of languages and
tools, ant seems to be more powerful and flexible.
If we only support a couple of Linux versions this might not be so
important.... and the ant builder can handle it easily.
Otherwise we can always trigger the cmake build for the C++ parts from
Ant....
Difficult decision really!
I think the need for a complete build system for this project is well
understood as there is none that builds the system from the repository.
Thanks to the batch scripts this is not too bad. But they dont cover
everything and are difficult to maintain and extend.
Also there are suttle dependencies on Environment vars etc... which are
hard to identify.
A good build system captures this information in the build script in a
central location within the repository.
If cmake can do everything we need, then it is a good option.
If it cannot do the lot but only parts of the build and we need
something else to complete the build, it might be not the best way to go....
THIS NEEDS MORE DISCUSSION.
Jackie Ng wrote:
> I agree that batch files are quite limiting, I didn't write them as the "be all, end all" build system for MapGuide. It was just something to improve the build experience on windows.
>
Indeed, I am happy that they are there as they helped me to get an
insight into the build process!
> Speaking as an ant non-expert, it does sound like ant would be the way to go, my questions on that are:
> 1) Can Ant integrate with msbuild and other build systems?
> 2) Can it integrate with helio's cmake work on linux?
>
> If yes on both, then I don't see why we can't use ant as the "one build system to rule them all". It's already required for building Fusion anyway, so there's no additional (software) overhead.
>
> - Jackie
>
>
> I always thought java is like C++ without the need for a preprocessor
> ;-) so I though its easy to read when you know C++.
> But I have a very multi language background so I cant really judge this.
>
> I encountered standalone java files in a previous job and was surprised
> how simple it is to just use it for simple tasks like this.
> And a lot less cryptic than any other script language I know....
>
> But my main point was to leverage the power of ant for such a task....
> so the script (at your portable language choice) does the replacement on
> a single file only...
> Ant then parses the source tree and applies the little script everywhere....
> I think this is a good investment into infrastructure.
>
> Once you have used ant for building software the use of batch files
> feels very limiting.
> and ant is multiplatform
> I think the multi-platform issue will become more of an issue over time.
> But thats a call for a PSC decision and introducing ant for parts of the
> build seems like a bigger project.
>
> I am willing to make a proposal when you tell me what needs to be done....
> The build process on the server still needs bit more work so its a good
> time to play around a bit.
>
> Cheers,
> UV
>
>
> Jason Birch wrote:
>
>> Yea, I started out wanting to use batch (was focussing on Windows build) and VBS was my (il)logical next step.
>>
>> Java is a non-starter for me (proficiency), and may make it harder to find people who can maintain it... in our current community anyway. I'd be willing to re-write in PHP at some point, which is at least supported on all platforms, and is one of MapGuide's three supported API languages.
>>
>> Jason
>>
>> ________________________________________
>> From: UV
>> Sent: Tuesday, April 07, 2009 6:45 PM
>> To: MapGuide Internals Mail List
>> Subject: Re: [mapguide-internals] Version setting script
>>
>> Good idea. Properly tagged source file are very helpful!
>>
>> just one thought....
>> do we need to introduce yet another scripting language into the system?
>> This is supposed to be multi-platform I thought._______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>>
>>
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>
>
>
More information about the mapguide-internals
mailing list