CMake builds clang.

Hi, Oscar

at all, it would be great if you reflect your changes on the file list
inside the corresponding CMakeLists.txt when you add, remove or rename

a

.cpp file.

Isn't is possible for cmake just to glob everything in the corresponding
directory?

"Anton Korobeynikov" <asl@math.spbu.ru> writes:

at all, it would be great if you reflect your changes on the file list
inside the corresponding CMakeLists.txt when you add, remove or rename
a .cpp file.

Isn't is possible for cmake just to glob everything in the corresponding
directory?

Yes, but then the build would not notice a change on the file
structure. You'll need to explicitly invoke cmake for being sure that
whatever changes were made by the last svn update are reflected on the
generated makefiles, which is a bigger incovenience than the occassional
modification of the CMakeLists.txt file.

I know this is a regression from the current build system, but the
amount of work it requires is dwarfed by the savings in global
maintenance.

Anton Korobeynikov a écrit :

Hi, Oscar

at all, it would be great if you reflect your changes on the file list
inside the corresponding CMakeLists.txt when you add, remove or rename

a

.cpp file.

Isn't is possible for cmake just to glob everything in the corresponding
directory?

Hi,

It is possible, but it has some drawback. Mainly, it won't check for new file itself and you would have to manually rerun CMake each times you add/remove a file.

The current makefile (gnu makefile) list all the files also, isn't it? they don't glob everythings.

just my 2cents.

Cédric

Cédric Venet <cedric.venet@laposte.net> writes:

It is possible, but it has some drawback. Mainly, it won't check for new
file itself and you would have to manually rerun CMake each times you
add/remove a file.

Not only the developer who added/renamed/removed a file, but all the
people using the svn sources.

The current makefile (gnu makefile) list all the files also, isn't it?
they don't glob everythings.

No. They use some clever mechanism for globbing the sources and adapt to
changes automatically.

Óscar Fuentes wrote:

"Anton Korobeynikov" <asl@math.spbu.ru> writes:

at all, it would be great if you reflect your changes on the file list
inside the corresponding CMakeLists.txt when you add, remove or rename a .cpp file.
      

Isn't is possible for cmake just to glob everything in the corresponding
directory?
    
Yes, but then the build would not notice a change on the file
structure. You'll need to explicitly invoke cmake for being sure that
whatever changes were made by the last svn update are reflected on the
generated makefiles, which is a bigger incovenience than the occassional
modification of the CMakeLists.txt file.
  

It would be simpler for autoconf builds to have a Perl script that updates the CMakeLists.txt files when necessary. (This doesn't look *that* hard, but I can't say when I'll surface long enough to work on that.)

Kenneth

Kenneth Boyd <zaimoni@zaimoni.com> writes:

Isn't is possible for cmake just to glob everything in the corresponding
directory?
    
Yes, but then the build would not notice a change on the file
structure. You'll need to explicitly invoke cmake for being sure that
whatever changes were made by the last svn update are reflected on the
generated makefiles, which is a bigger incovenience than the occassional
modification of the CMakeLists.txt file.
  

It would be simpler for autoconf builds to have a Perl script that
updates the CMakeLists.txt files when necessary. (This doesn't look
*that* hard, but I can't say when I'll surface long enough to work on that.)

In theory, it is possible to do this with cmake itself. In practice, it
doesn't matter much because:

1) either CMake becomes the de facto standard for LLVM, deprecating
autoconf&&gmake and thus requiring the developers to update the
CMakeLists.txt files to compile their sources...

2) ... or CMake remains a fall-back system for those not covered by
autoconf&&gmake, with most LLVM developers ignoring it and requiring
some periodic maintence work by those who use it.

If the tendency is towards (2), I'll implement a cmake option for
checking that the files contained in each CMakeLists.txt matches those
on its respective directory, reporting the differences. Checking the
discrepancies is easy, patching the CMakeLists.txt file is not, in the
general case, either for a Perl script or for CMake itself. So, Kenneth,
don't waste your time on this.

Óscar Fuentes wrote:

Kenneth Boyd <zaimoni@zaimoni.com> writes:

Isn't is possible for cmake just to glob everything in the corresponding
directory?
    

Yes, but then the build would not notice a change on the file
structure. You'll need to explicitly invoke cmake for being sure that
whatever changes were made by the last svn update are reflected on the
generated makefiles, which is a bigger incovenience than the occassional
modification of the CMakeLists.txt file.
  

It would be simpler for autoconf builds to have a Perl script that updates the CMakeLists.txt files when necessary. (This doesn't look *that* hard, but I can't say when I'll surface long enough to work on that.)
    
In theory, it is possible to do this with cmake itself. In practice, it
doesn't matter much because:

1) either CMake becomes the de facto standard for LLVM, deprecating
autoconf&&gmake and thus requiring the developers to update the
CMakeLists.txt files to compile their sources...
  

Sorry, but this is a noticeable obstacle for CMake becoming the de-facto standard for LLVM.

From the existence of the dependency-tracker scripts, it obviously was a problem for autoconf as well.

2) ... or CMake remains a fall-back system for those not covered by
autoconf&&gmake, with most LLVM developers ignoring it and requiring
some periodic maintence work by those who use it.

If the tendency is towards (2), I'll implement a cmake option for
checking that the files contained in each CMakeLists.txt matches those
on its respective directory, reporting the differences.

I think this option would be useful anyway.

Checking the
discrepancies is easy, patching the CMakeLists.txt file is not, in the
general case, either for a Perl script or for CMake itself.

The general case doesn't matter.

The specific case we're talking about appears easy (in Perl: it's just adjusting *one* variable in the CMakeList.txt), and as I see the development workflow critical for option 1.

Kenneth

FWIW, when it is ready, I'd strongly prefer to use cmake for everything. We should have one build system to rule them all, and the whole reason that cmake seems awesome is that it covers all the build hosts we care about.

That said, I don't really think the file globbing is that big of a "feature". If it turns out that we don't get it with cmake, that's ok.

-Chris

Kenneth Boyd <zaimoni@zaimoni.com> writes:

1) either CMake becomes the de facto standard for LLVM, deprecating
autoconf&&gmake and thus requiring the developers to update the
CMakeLists.txt files to compile their sources...
  

Sorry, but this is a noticeable obstacle for CMake becoming the de-facto
standard for LLVM.

Writing a new cpp file: minutes to hours.
Adding it to its corresponding CMakeLists.txt: less that 10 seconds.

I created the CMakeLists.txt files for all Clang source tree yesterday
in less than 15 minutes, and it involved much more than writing lists of
cpp files.

From the existence of the dependency-tracker scripts, it obviously was
a problem for autoconf as well.

This seems a different issue, but are those dependency-tracker scripts
for tracking dependencies among cpp files and its headers? CMake gives
you this for free and it is not restricted to gcc.

If the tendency is towards (2), I'll implement a cmake option for
checking that the files contained in each CMakeLists.txt matches those
on its respective directory, reporting the differences.

I think this option would be useful anyway.

Agreed. But right now I prefer to avoid adding features that would
justify any kind of inaction by the developers. I want get them
involved.

Checking the
discrepancies is easy, patching the CMakeLists.txt file is not, in the
general case, either for a Perl script or for CMake itself.

The general case doesn't matter.

It matters a lot. One nice thing about CMake is that it provides means
for abstracting things. So you see add_llvm_library, which is
llvm-specific macro, instead of the standard add_library. Assuming that
add_llvm_library will work on the future as it works now would lead to
problems at some point.

[snip]

Óscar Fuentes wrote:

Kenneth Boyd <zaimoni@zaimoni.com> writes:

  .....

From the existence of the dependency-tracker scripts, it obviously was a problem for autoconf as well.
    
This seems a different issue, but are those dependency-tracker scripts
for tracking dependencies among cpp files and its headers? CMake gives
you this for free and it is not restricted to gcc.
  

GenLibDeps.pl tracks direct dependencies between the primary library and object files intended to be linked (*.a and *.o on a *NIX-like system). Other parts of the LLVM build modifications to autoconf walk this to determine which libraries have to be linked in.

Kenneth

Chris Lattner <clattner@apple.com> writes:

[snip]

That said, I don't really think the file globbing is that big of a
"feature". If it turns out that we don't get it with cmake, that's
ok.

Automatic file globbing is, at least on GNU systems, possible with
CMake. It would require some added complexity, and this I want to
avoid.

File globbing saves a minute or two per year and developer. Just one
broken build caused, directly or indirectly, by a bug on this feature
would send down the drain all the time you saved on the whole life of
the LLVM project.

OTOH, achieving a build system that is efficient and easy to maintain
would be a major gain. Once it is finished, I expect that some minutes
of study would be enough for understanding how the LLVM CMake build
system works. Add an hour more and you will be ready for some major
maintenance work, without previous CMake experience. Apart from its
multiplatform, multitool character, this is where CMake is vastly
superior to autoconf & gmake.

I completely agree,

-Chris

Kenneth Boyd <zaimoni@zaimoni.com> writes:

From the existence of the dependency-tracker scripts, it obviously was
a problem for autoconf as well.

This seems a different issue, but are those dependency-tracker scripts
for tracking dependencies among cpp files and its headers? CMake gives
you this for free and it is not restricted to gcc.
  

GenLibDeps.pl tracks direct dependencies between the primary library and
object files intended to be linked (*.a and *.o on a *NIX-like system).
Other parts of the LLVM build modifications to autoconf walk this to
determine which libraries have to be linked in.

This same mechanism is used by the CMake build, but I can't see how this
is related to source file globbing in the makefiles.